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:​

Last updated on by Kim Carter