Skip to main content

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:

Security Misconfiguration

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โ€‹

  1. Set your Pod Security Policy so that spec.allowedProcMountTypes contains the value Default and not Unmasked
  2. Test it
  3. 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โ€‹

  1. 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 value

  2. Test it

  3. 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โ€‹

  1. Go through the issues that GuardRails identified in the PR

  2. Look for code like this:

    apiVersion: v1
    kind: Pod
    metadata:
    name: volume-hostpath
    spec:
    []...]
    volumes:
    - name: test-volume
    hostPath:
    path: /var/run/docker.sock
  3. And remove any paths that mount the docker.sock

  4. Test it

  5. 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โ€‹

  1. Go through the issues that GuardRails identified

  2. 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.
  3. Replace the line containing readOnlyRootFilesystem: false with:

    spec:  
    containers:
    # specification of the podโ€™s containers
    # ...
    securityContext:
    readOnlyRootFilesystem: true
  4. Test it

  5. 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โ€‹

  1. Go through the issues that GuardRails identified

  2. Identify container specs that don't have resource limitations

  3. 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"
  4. Test it

  5. Ship it ๐Ÿšข and relax ๐ŸŒด

PSP With Added Capabilitiesโ€‹

Option A: Make sure AllowedCapabilities is Emptyโ€‹

PodSecurityPolicy should not have added capabilities.

  1. Set your Pod Security Policy so that spec.allowedCapabilities either does not exist or does not contain any capabilities
  2. Test it
  3. Ship it ๐Ÿšข and relax ๐ŸŒด

References:โ€‹

More information:โ€‹