From the course: Certified Kubernetes Administrator (CKA) Cert Prep

Managing security context - Kubernetes Tutorial

From the course: Certified Kubernetes Administrator (CKA) Cert Prep

Start my 1-month free trial Buy for my team

Managing security context

“

- In this video, you'll learn about SecurityContext. SecurityContext defines privilege and access control settings for Pods or containers or both And it can include a couple of settings: UID and GID- based Discretionary Access Control. That is basic Linux access control, so Linux permissions and ownership. SELinux is some advanced Linux security that you will find on Red Hat, mainly. Linux capabilities, these are additional administrator-like permissions that can be set. AppArmor or Seccomp, which are other security mechanisms. The AllowPrivilegeEscalation setting to define whether or not you allow your Pod to escalate privileges, or the opposite, the runAsNonRoot setting, which denies your Pod to use Root privileges. SecurityContext can be set at the Pod level as well as the container level, and if you set at container level and you have the same setting at Pod level, more specific will always win. You should know that between Pods and container, the settings are not exactly the same and that is why you might want to check out Cube ctl, kubectl explain pod.spec.securityContext as well as kubectl explain pod.spec.containers.securityContext because as I just mentioned, they're different. Now let me demonstrate. In this demo, we are going to run a YAML file that has some pre-configured SecurityContexts because unfortunately you cannot easily set SecurityContext from the command line, it always goes through YAML. So in this YAML file, we are going to explore some SecurityContext settings. Now you might think nice that we have YAML file as example here, well, how about the exam? And you are right thinking that because on the exam, you don't have access to make it repository. But fortunately there's kubernetes.io/docks in which you have SecurityContext including a pretty nice example. There you go, SecurityContext at a container level and here we have a SecurityContext at the Pod level. So at the exam, that's what you can use. I don't want to use that, I want to use my YAML here. So security-context.yaml, what do we see? We see a Pod spec and on the Pod spec, we have "runAsUser", "runAsGroup", and "fsGroup". Then we have volumes, that's a shared volume with the name "securevol", an "emptyDir" type, and we have containers. And the container is running BusyBox with the sleep command, and it mounts the volume on "/data/demo", and it also sets "allowPrivilegeEscalation" to false at a container level. So I need to apply that using "kubectl apply - f" on "security-context.yaml" and then we can check it out using "kubectl get pods" and we can see it's running SecurityContext demo. Now I would like to execute command in there. So "kubectl exec - it security-context-demo - -sh" Then I'm using "ps". And in "ps", we can already see the user ID that I've set in the SecurityContext. That is User ID 1000. Now I'm going in the data directory. I'm using "ls - l" and we see a demo directory which says the file system group ID set to 2000. User ID is showing my current User ID 1000. My groups are set to 1000 and 2000, meaning that even if my primary group is 1000, when I create files, I get this secondary group set to 2000 and uh-oh, unfortunately, I don't have permissions to create files. That is true because I'm a limited user, after all. So the only thing that makes sense that I can do right now is exit. This is showing how SecurityContext is working.

Contents