Insecure Configuration
Why is this important?โ
Kubernetes is a complex platform that in many cases puts a higher priority on Developer experience than secure defaults.
Check out this video for a high-level explanation:
Container Runs Unmaskedโ
Option A: Make sure AllowedProcMountTypes is Set to Defaultโ
Check if a container has full access (Unmasked
) to the host's /proc
command, which would allow to retrieve sensitive information and possibly change the kernel parameters at runtime.
Detailed Instructionsโ
- Set your Pod Security Policy so that
spec.allowedProcMountTypes
contains the valueDefault
and notUnmasked
- Test it
- Ship it ๐ข and relax ๐ด
Referencesโ
Default Service Account In Useโ
Option A: Make sure AutomountServiceAccountToken is set to falseโ
Default service accounts should not be actively used
Detailed Instructionsโ
opt out of automounting API credentials for a service account by setting
automountServiceAccountToken: false
on the service account:apiVersion: v1
kind: ServiceAccount
metadata:
name: build-robot
automountServiceAccountToken: false
...In version 1.6+, you can also opt out of automounting API credentials for a particular pod:
apiVersion: v1
kind: Pod
metadata:
name: my-pod
spec:
serviceAccountName: build-robot
automountServiceAccountToken: false
...The pod spec takes precedence over the service account if both specify an
automountServiceAccountToken
valueTest it
Ship it ๐ข and relax ๐ด
References:โ
Fixing Insecure Volumes Configurationโ
Option A: Don't mount the docker socketโ
Mounting the docker.socket
leaks information about other containers and in some instances can allow container breakout.
Detailed Instructionsโ
Go through the issues that GuardRails identified in the PR
Look for code like this:
apiVersion: v1
kind: Pod
metadata:
name: volume-hostpath
spec:
[]...]
volumes:
- name: test-volume
hostPath:
path: /var/run/docker.sockAnd remove any paths that mount the
docker.sock
Test it
Ship it ๐ข and relax ๐ด
Insecure Security Context Configurationโ
Option A: Leverage immutable root file-systemsโ
An immutable root filesystem can prevent malicious binaries being added to PATH and increase attack cost as well as avoid modification of the application source at runtime.
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:
readOnlyRootFilesystem: false
# it is also possible for readOnlyRootFilesystem to not be set.Replace the line containing
readOnlyRootFilesystem: false
with:spec:
containers:
# specification of the podโs containers
# ...
securityContext:
readOnlyRootFilesystem: trueTest it
Ship it ๐ข and relax ๐ด
Missing Resource Limitationsโ
Kubernetes allows setting resource limitations on CPU and memory which can be useful to prevent denial of service attacks, or very high cloud provider bills. While this is not a high risk issue, it is considered best practice to set these limitations.
Option A: Enforce limitsโ
Enforcing CPU/memory requests aids a fair balancing of resources across the cluster. Enforcing CPU/memory limits prevents DOS via resource exhaustion.
Detailed Instructionsโ
Go through the issues that GuardRails identified
Identify container specs that don't have resource limitations
Add CPU and memory limitations to the configuration
apiVersion: v1
kind: Pod
metadata:
name: default-mem-demo-3
spec:
containers:
- name: default-mem-demo-3-ctr
image: nginx
resources:
requests:
memory: "128Mi"
cpu: 500m
limits:
memory: "512Mi"
cpu: "1"Test it
Ship it ๐ข and relax ๐ด
PSP With Added Capabilitiesโ
Option A: Make sure AllowedCapabilities is Emptyโ
PodSecurityPolicy should not have added capabilities.
- Set your Pod Security Policy so that
spec.allowedCapabilities
either does not exist or does not contain any capabilities - Test it
- Ship it ๐ข and relax ๐ด