Question 18733 in Amazon Web Sevices Question posted in
The official Amazon Web Services documentation can be found here.

k8s check pod securityContext definition – Amazon Web Sevices

I want to check if pod in the cluster running as privileged pods, which can indicate that we may have security issue, so I check if
privileged: true

However under the
securityContext: spec there is additional fields like

  • allowPrivilegeEscalation
  • RunAsUser
  • ProcMount
  • Capabilities
    etc

Which may be risky (not sure about it) ,

My question is in case the pod is marked as privileged:false and the other fields are true like the following example,if this indicate some security issue ? Does this pods can do some operation on other pods etc , access external data?

For example the following configuration which indicate the the pod is not privileged but allowPrivilegeEscalation: true

securityContext:
  allowPrivilegeEscalation: true
  privileged: false

I want to know which securityContext combination of pod config can control other pods/process in the cluster ?

Tags:

2

Answers


  1. 0

    The securityContext are more related to the container itself and some access to the host machine.

    The allowPrivilegeEscalation allow a process to gain more permissions than its parent process. This is more related to setuid/setgid flags in binaries, but inside a container there is no much to get worried about.

    You can only control other containers in the host machine from inside a container if you have a hostPath volume, or something like that, allowing you to reach the .sock file as /run/crio/crio.sock or the docker.sock. Is pretty obvious that, if you are concerned about this, allowing requests to Docker API through the network should be disabled.

    Of course, all of these access are ruled by DAC and MAC restrictions. This is why podman uidmap is better, because the root inside the container do not have the same root id outside the container.

    From Kubernetes point of view, you don’t need this kind of privileges, all you need is a ServiceAccount and the correct RBAC permissions to control other things inside Kubernetes. A ServiceAccount binded to a cluster-admin ClusterRole can do anything in the API and much more, like adding ssh keys to the hosts.

    If you are concerned about pods executing things in Kubernetes or in the host, just force the use of nonRoot containers, avoid indiscriminate use of hostPath volumes, and control your RBAC.

    Openshift uses a very nice restriction by default:

    • Ensures that pods cannot run as privileged
    • Ensures that pods cannot mount host directory volumes
    • Requires that a pod is run as a user in a pre-allocated range of UIDs (openshift feature, random uid)
    • Requires that a pod is run with a pre-allocated MCS label (selinux related)

    I don’t answer exactly what you want, because I shifted the attention to RBAC, but I hope this can give you a nice idea.

    Login or Signup to reply.
  2. 0

    Strictly in the scope of securityContext (as of Kubernetes 1.26 API), here’s few things that may be risky:

    Certainly risky

    • capabilities.add will add Linux capabilities (like CAP_SYS_TIME to set system time) to a container. The default depends on container runtime (see for example Docker default set of capabilities) and should be reasonably secure, but adding capabilities like CAP_SYS_ADMIN may represent a risk. Excessive capabilities outlines a few possible escalations.
    • privileged: true grants all capabilities, so you’ll definitely want to check for that (as you already do).
    • allowPrivilegeEscalation: true is risky as it allow a process to gain more privileges than its parent.
    • procMount will allow a container mounting node’s /proc and expose sensible host information.
    • windowsOptions may be risky. According to Kubernetes doc it enables privileged access to the Windows node. I don’t know much about Windows security, but I’d say risky 🙂

    Maybe risky (though usually intended to restrict permissions)

    • runAsGroup and runAsUser may be risky when set to root / 0. Given that by default container runtime will probably run container as root already it’s mostly used to restrict container’s permissions to a non-root user. But if your container runtime is configured to run container as non-root by default, it might be used to bypass that and run a container with root.
    • seLinuxOptions may be used to provide an insecure SELinux context, but is usually intended to define a more secure context.
    • seccompProfile defines system calls a container is allowed to make. It may be used to get access to sensitive system calls, though it’s usually intended to restrict them.

    (probably) Not risky

    • readOnlyRootFilesystem (default false) will make container root system read-only.
    • runAsNonRoot (default false) will prevent a container from running as root
    • capabilities.drop will drop Linux capabilities, restricting further what a container can do.

    You can read more on Configure a Security Context official doc

    What about non-Security Context related risks?

    Security Context is not the only thing you should be wary about: you should also consider volume mounts to unsecure locations, RBAC, network, Secrets, etc. A good overview is provided by Security Checklist.

    Login or Signup to reply.
Please signup or login to give your own answer.

Back To Top
Search