Insecure Access Control
Why is this important?
Access Control is one of the most fundamental security requirements. Any problem with managing access control can allow attackers to bypass business logic and access data from other users. In the context of Kubernetes this affects settings related to the securityContext and spec.
Check out this video for a high-level explanation:
Insecure SecurityContext Settings
This category refers to SecurityContext settings that are insecure at the pod or container level.
Option A: Run containers as non-root users
Force the running image to run as a non-root user to ensure least privilege.
Detailed Instructions
Go through the issues that GuardRails identified
Look for code like this:
apiVersion: v1
kind: Pod
metadata:
name: security-best-practice
spec:
containers:
# specification of the pod’s containers
# ...
securityContext:
runAsNonRoot: false
# it is also possible for runAsNonRoot to not be set.Replace the line containing
runAsNonRoot: false
with:spec:
containers:
# specification of the pod’s containers
# ...
securityContext:
runAsNonRoot: trueTest it
Ship it 🚢 and relax 🌴
Option B: Don't run containers in privileged mode
Privileged containers can allow almost completely unrestricted host access.
Detailed Instructions
Go through the issues that GuardRails identified
Look for code like this:
apiVersion: v1
kind: Pod
metadata:
name: security-best-practice
spec:
containers:
# specification of the pod’s containers
# ...
securityContext:
privileged: trueReplace the line containing
privileged: false
with:spec:
containers:
# specification of the pod’s containers
# ...
securityContext:
privileged: falseTest it
Ship it 🚢 and relax 🌴
Option C: Don't add SYS_ADMIN capabilities
Capabilities permit certain named root actions without giving full root access. They are a more fine-grained permissions model, and all capabilities should be dropped from a pod, with only those required added back.
There are a large number of capabilities, with CAP_SYS_ADMIN bounding most. Never enable this capability - it’s equivalent to root and should always be avoided.
Detailed Instructions
Go through the issues that GuardRails identified
Look for code like this:
apiVersion: v1
kind: Pod
metadata:
name: sys-admin-capabilities
spec:
containers:
# specification of the pod’s containers
# ...
securityContext:
capabilities:
drop:
- all
add:
- SYS_ADMINRemove the
SYS_ADMIN
capabilitiesTest it
Ship it 🚢 and relax 🌴
Option D: Disable allowPrivilegeEscalation
Gates whether or not a user is allowed to set the security context of a container to allowPrivilegeEscalation. This defaults to allowed so as to not break setuid binaries. Setting it to false ensures that no child process of a container can gain more privileges than its parent.
Detailed Instructions
Go through the issues that GuardRails identified
Look for container definitions with
allowPrivilegeEscalation
being set to trueapiVersion: v1
kind: Pod
metadata:
name: drop-capabilities
spec:
containers:
# specification of the pod’s containers
# ...
securityContext:
allowPrivilegeEscalation: trueChange it to
allowPrivilegeEscalation: false
Test it
Ship it 🚢 and relax 🌴
Option E: Reduce kernel capabilities
Reducing kernel capabilities available to a container limits its attack surface. It's recommended to drop all capabilities and only add the ones specifically needed.
Detailed Instructions
Go through the issues that GuardRails identified
Look for container definitions without capabilities definition in the securityContext
Drop all capabilities and only add the ones needed
apiVersion: v1
kind: Pod
metadata:
name: drop-capabilities
spec:
containers:
# specification of the pod’s containers
# ...
securityContext:
capabilities:
drop:
- all
add: ["NET_ADMIN", "SYS_TIME"]Or better yet:
apiVersion: v1
kind: Pod
metadata:
name: drop-capabilities
spec:
containers:
# specification of the pod’s containers
# ...
securityContext:
capabilities:
drop:
- all
add: ["NET_BIND_SERVICE"]Test it
Ship it 🚢 and relax 🌴
Option F: Run as high-UID user
Run as a high-UID user to avoid conflicts with the host's user table. While this is not a high-risk issue it is recommended to set a UID higher than 10000.
Detailed Instructions
Go through the issues that GuardRails identified
Look for container definitions like this:
apiVersion: v1
kind: Pod
metadata:
name: run-as-user
spec:
containers:
# specification of the pod’s containers
# ...
securityContext:
runAsUser: 1000Change the value to a number higher than 10000
Test it
Ship it 🚢 and relax 🌴
Insecure Spec Settings
This category refers to Spec settings that are insecure.
Option A: Disable HostPID
Sharing the host's PID namespace allows visibility of processes on the host, potentially leaking information such as environment variables and configuration.
Detailed Instructions
Go through the issues that GuardRails identified
Look for spec definitions like this:
apiVersion: v1
kind: Pod
metadata:
name: run-as-user
spec:
hostPID: trueChange the value of
hostPID
tofalse
Test it
Ship it 🚢 and relax 🌴
References:
Not Limited Capabilities For Pod Security Policy
Option A:
Usually the best approach when it comes to the set of capabilities that pods can run with is to remove them until something in your application stops working, or start with no capabilities and only add the ones you fnd you need. The fewer Linux capabilities you run with the less privileges and access the containers within the given pod have to the hosts kernel.
Detailed Instructions
At the Pod Security Policy level:
- Add as many capabilities to
requiredDropCapabilities
of your Pod Security Policy as possible, or even addALL
- Test your application
- If everything is still working try adding more capabilities to
requiredDropCapabilities
- Test your application, if something has stopped working, remove the capability you just added to
requiredDropCapabilities
- Test your application
- If everything is still working, ship it 🚢 and relax 🌴
References:
- Define Capabilities with Pod Security Policy
- Holistic Info-Sec for Web Developers - Capabilities Risks, Countermeasures