Update deployment.yaml

[try-panwiac]

No description provided.

[prisma-cloud-devsecops]

  Images are not selected using a digest
    Resource: Deployment.default.build-code-deployment | ID: BC_K8S_39

How to Fix

apiVersion: v1
kind: Pod
metadata:
  name: <Pod name>
spec:
  containers:
  - name: <container name>
    image: image@sha256:45b23dee08af5e43a7fea6c4cf9c25ccf269ee113168c19722f87876677c5cb2

Description

In some cases you may prefer to use a fixed version of an image, rather than update to newer versions. Docker enables you to pull an image by its digest, specifying exactly which version of an image to pull.

Pulling using a digest allows you to “pin” an image to that version, and guarantee that the image you’re using is always the same. Digests also prevent race-conditions; if a new image is pushed while a deploy is in progress, different nodes may be pulling the images at different times, so some nodes have the new image, and some have the old one. Services automatically resolve tags to digests, so you don't need to manually specify a digest.

[prisma-cloud-devsecops]

  securityContext is not applied to pods and containers
    Resource: Deployment.default.build-code-deployment | ID: BC_K8S_28

How to Fix

apiVersion: v1
kind: Pod
metadata:
  name: <Pod name>
spec:
  containers:
  - name: <container name>
    image: <image>
+   securityContext:

Description

**securityContext** defines privilege and access control settings for your pod or container, and holds security configurations that will be applied to a container. Some fields are present in both **securityContext** and **PodSecurityContext**, when both are set, **securityContext** takes precedence.

Well-defined privilege and access control settings will enhance assurance that your pod is running with the properties it requires to function.

Benchmarks

• CIS KUBERNETES V1.5 1.6.5
• CIS GKE V1.1 4.6.3
• CIS EKS V1.1 4.6.2
• CIS KUBERNETES V1.6 5.7.3

[prisma-cloud-devsecops]

  CPU request is not set
    Resource: Deployment.default.build-code-deployment | ID: BC_K8S_9

How to Fix

apiVersion: v1
kind: Pod
metadata:
  name: <name>
spec:
  containers:
  - name: <container name>
    image: <image>
    resources:
      requests:
+       cpu: <cpu request>

Description

When specifying the resource request for containers in a pod, the scheduler uses this information to decide which node to place the pod on. When setting resource limit for a container, the kubelet enforces those limits so that the running container is not allowed to use more of that resource than the limit you set.

If a container is created in a namespace that has a default CPU limit, and the container does not specify its own CPU limit, then the container is assigned the default CPU limit. Kubernetes assigns a default CPU request under certain conditions.

[prisma-cloud-devsecops]

  Default namespace is used
    Resource: Service.default.build-code-service | ID: BC_K8S_20

How to Fix

apiVersion: <apiVersion>
kind: <kind>
metadata:
  name: <name>
+ namespace: <your namespace>
- namespace: default

Description

In Kubernetes, the cluster comes out of the box with a namespace called “default.” Other namespaces Kubernetes includes are: default, kube-system and kube-public. Some Kubernetes tooling is set up out of the box to use this namespace and you can’t delete it.

We recommend that you do not use the default namespace in large production systems. Using this space can result in accidental disruption with other services. Instead, we recommend you create alternate namespaces and use them to run additional required services.

Benchmarks

• PCI-DSS V3.2 2
• CIS KUBERNETES V1.5 1.6.2

[prisma-cloud-devsecops]

  Read-Only filesystem for containers is not used
    Resource: Deployment.default.build-code-deployment | ID: BC_K8S_21

How to Fix

apiVersion: v1
kind: Pod
metadata:
  name: <Pod name>
spec:
  containers:
  - name: <container name>
    image: <image>
    securityContext:
+      readOnlyRootFilesystem: true

Description

A read-only root filesystem helps to enforce an immutable infrastructure strategy. The container should only write on mounted volumes that can persist, even if the container exits.

Using an immutable root filesystem and a verified boot mechanism prevents against attackers from "owning" the machine through permanent local changes. An immutable root filesystem can also prevent malicious binaries from writing to the host system.

[prisma-cloud-devsecops]

  Admission of root containers not minimized
    Resource: Deployment.default.build-code-deployment | ID: BC_K8S_22

How to Fix

apiVersion: v1
kind: Pod
metadata:
  name: <name>
spec:
	securityContext:
+ 	runAsNonRoot: true
+ 	runAsUser: <specific user>

Description

Containers rely on the traditional Unix security model granting explicit and implicit permissions to resources, through permissions granted to users and groups. User namespaces are not enabled in Kubernetes. The container's user ID table maps to the host's user table, and running a process as the root user inside a container runs it as root on the host. Although possible, we do not recommend running as root inside the container.

Containers that run as root usually have far more permissions than their workload requires. In case of compromise, an attacker can use these permissions to further an attack on the network. Several container images use the root user to run PID 1. An attacker will have root permissions in the container and be able to exploit mis-configurations.

Benchmarks

• SOC2 CC6.3.4
• HIPAA 164.312(A)(1) Access control
• CIS KUBERNETES V1.5 1.7.6
• CIS GKE V1.1 4.2.6
• CIS EKS V1.1 4.2.6
• CIS KUBERNETES V1.6 5.2.6

[prisma-cloud-devsecops]

  Liveness probe is not configured
    Resource: Deployment.default.build-code-deployment | ID: BC_K8S_7

How to Fix

apiVersion: v1
kind: Pod
metadata:
  name: <name>
spec:
  containers:
  - name: <container name>
    image: <image>
+   livenessProbe:
      <Probe arguments>

Description

The kubelet uses liveness probes to know when to schedule restarts for containers. Restarting a container in a deadlock state can help to make the application more available, despite bugs.

If a container is unresponsive, either to a deadlocked application or a multi-threading defect, restarting the container can make the application more available, despite the defect.

[prisma-cloud-devsecops]

  Containers do not run with a high UID
    Resource: Deployment.default.build-code-deployment | ID: BC_K8S_37

How to Fix

apiVersion: v1
kind: Pod
metadata:
  name: <name>
spec:
	securityContext:
+ 	runAsUser: <UID higher then 10000>

Description

Linux namespaces provide isolation for running processes and limits access to system resources. To prevent privilege-escalation attacks from within a container, we recommend that you configure your container’s applications to run as unprivileged users. The mapped user is assigned a range of UIDs which function within the namespace as normal UIDs from 0 to 65536, but have no privileges on the host machine itself.

If a process attempts to escalate privilege outside of the namespace, the process is running as an unprivileged high-number UID on the host, not mapped to a real user. This means the process has no privileges on the host system and cannot be attacked by this method.

This check will trigger below UID 10,000 as common linux distributions will assign UID 1000 to the first non-root, non system user and 1000 users should provide a reasonable buffer.

[prisma-cloud-devsecops]

  Readiness probe is not configured
    Resource: Deployment.default.build-code-deployment | ID: BC_K8S_8

How to Fix

apiVersion: v1
kind: Pod
metadata:
  name: <name>
spec:
  containers:
  - name: <container name>
    image: <image>
+   readinessProbe:
      <Probe configurations>

Description

Readiness Probe is a Kubernetes capability that enables teams to make their applications more reliable and robust. This probe regulates under what circumstances the pod should be taken out of the list of service endpoints so that it no longer responds to requests. In defined circumstances the probe can remove the pod from the list of available service endpoints.

Using the Readiness Probe ensures teams define what actions need to be taken to prevent failure and ensure recovery in case of unexpected errors.

Kubernetes.io Documentation

[prisma-cloud-devsecops]

  Containers run with AllowPrivilegeEscalation
    Resource: Deployment.default.build-code-deployment | ID: BC_K8S_19

How to Fix

apiVersion: v1
kind: Pod
metadata:
  name: <Pod name>
spec:
  containers:
  - name: <container name>
    image: <image>
    securityContext:
+      allowPrivilegeEscalation: false

Description

The **AllowPrivilegeEscalation** Pod Security Policy controls whether or not a user is allowed to set the security context of a container to **True**. Setting it to **False** ensures that no child process of a container can gain more privileges than its parent.

We recommend you to set AllowPrivilegeEscalation to False, to ensure RunAsUser commands cannot bypass their existing sets of permissions.

Benchmarks

• SOC2 CC6.3.4
• HIPAA 164.312(A)(1) Access control
• CIS KUBERNETES V1.5 1.7.5
• CIS GKE V1.1 4.2.5
• CIS EKS V1.1 4.2.5
• CIS KUBERNETES V1.6 5.2.5

[prisma-cloud-devsecops]

  Default namespace is used
    Resource: Deployment.default.build-code-deployment | ID: BC_K8S_20

How to Fix

apiVersion: <apiVersion>
kind: <kind>
metadata:
  name: <name>
+ namespace: <your namespace>
- namespace: default

Description

In Kubernetes, the cluster comes out of the box with a namespace called “default.” Other namespaces Kubernetes includes are: default, kube-system and kube-public. Some Kubernetes tooling is set up out of the box to use this namespace and you can’t delete it.

We recommend that you do not use the default namespace in large production systems. Using this space can result in accidental disruption with other services. Instead, we recommend you create alternate namespaces and use them to run additional required services.

Benchmarks

• PCI-DSS V3.2 2
• CIS KUBERNETES V1.5 1.6.2

[prisma-cloud-devsecops]

  seccomp is not set to Docker/Default or Runtime/Default
    Resource: Deployment.default.build-code-deployment | ID: BC_K8S_29

How to Fix

apiVersion: v1
kind: Pod
metadata:
  name: <name>
  annotations:
+  	seccomp.security.alpha.kubernetes.io/pod: "docker/default" 
	or
+   seccomp.security.alpha.kubernetes.io/pod: "runtime/default"

Description

Secure computing mode (seccomp) is a Linux kernel feature used to restrict actions available within the container. The seccomp() system call operates on the seccomp state of the calling process. The default seccomp profile provides a reliable setting for running containers with seccomp and disables non-essential system calls.

Benchmarks

• PCI-DSS V3.2 2
• CIS KUBERNETES V1.5 1.6.4
• CIS GKE V1.1 4.6.2
• CIS EKS V1.1 4.6.1
• CIS KUBERNETES V1.6 5.7.2

[prisma-cloud-devsecops]

  Admission of containers with capabilities assigned is not limited
    Resource: Deployment.default.build-code-deployment | ID: BC_K8S_34

How to Fix

apiVersion: v1
kind: Pod
metadata:
  name: <Pod name>
spec:
  containers:
  - name: <container name>
    image: <image>
    securityContext:
      capabilities:
		drop:
+         - ALL

Description

Docker has a default list of capabilities that are allowed for each container of a pod. The containers use the capabilities from this default list, but pod manifest authors can alter it by requesting additional capabilities, or dropping some of the default capabilities.

Limiting the admission of containers with capabilities ensures that only a small number of containers have extended capabilities outside the default range. This helps ensure that if a container becomes compromised it is unable to provide a productive path for an attacker to move laterally to other containers in the pod.

Benchmarks

• SOC2 CC6.3.4
• CIS KUBERNETES V1.5 1.7.7
• CIS GKE V1.1 4.2.9
• CIS EKS V1.1 4.2.9
• CIS KUBERNETES V1.6 5.2.9

[prisma-cloud-devsecops]

  Admission of containers with NET_RAW capability is not minimized
    Resource: Deployment.default.build-code-deployment | ID: BC_K8S_27

How to Fix

apiVersion: v1
kind: Pod
metadata:
  name: <Pod name>
spec:
  containers:
  - name: <container name>
    image: <image>
    securityContext:
      capabilities:
		drop:
+        - NET_RAW
+        - ALL

Description

NET_RAW capability allows the binary to use RAW and PACKET sockets as well as binding to any address for transparent proxying. The *ep* stands for “effective” (active) and “permitted” (allowed to be used).

With Docker as the container runtime NET_RAW capability is enabled by default and may be misused by malicious containers. We recommend you define at least one PodSecurityPolicy (PSP) to prevent containers with NET_RAW capability from launching.

Benchmarks

• SOC2 CC6.3.4
• CIS KUBERNETES V1.5 1.7.7
• CIS GKE V1.1 4.2.7
• CIS EKS V1.1 4.2.7
• CIS KUBERNETES V1.6 5.2.7

[prisma-cloud-devsecops]

  Containers do not run with a high UID
    Resource: Deployment.default.build-code-deployment | ID: BC_K8S_37

How to Fix

apiVersion: v1
kind: Pod
metadata:
  name: <name>
spec:
	securityContext:
+ 	runAsUser: <UID higher then 10000>

Description

Linux namespaces provide isolation for running processes and limits access to system resources. To prevent privilege-escalation attacks from within a container, we recommend that you configure your container’s applications to run as unprivileged users. The mapped user is assigned a range of UIDs which function within the namespace as normal UIDs from 0 to 65536, but have no privileges on the host machine itself.

If a process attempts to escalate privilege outside of the namespace, the process is running as an unprivileged high-number UID on the host, not mapped to a real user. This means the process has no privileges on the host system and cannot be attacked by this method.

This check will trigger below UID 10,000 as common linux distributions will assign UID 1000 to the first non-root, non system user and 1000 users should provide a reasonable buffer.

[prisma-cloud-devsecops]

  securityContext is not applied to pods and containers
    Resource: Deployment.default.build-code-deployment | ID: BC_K8S_28

How to Fix

apiVersion: v1
kind: Pod
metadata:
  name: <Pod name>
spec:
  containers:
  - name: <container name>
    image: <image>
+   securityContext:

Description

**securityContext** defines privilege and access control settings for your pod or container, and holds security configurations that will be applied to a container. Some fields are present in both **securityContext** and **PodSecurityContext**, when both are set, **securityContext** takes precedence.

Well-defined privilege and access control settings will enhance assurance that your pod is running with the properties it requires to function.

Benchmarks

• CIS KUBERNETES V1.5 1.6.5
• CIS GKE V1.1 4.6.3
• CIS EKS V1.1 4.6.2
• CIS KUBERNETES V1.6 5.7.3

[prisma-cloud-devsecops]

  securityContext is not applied to pods and containers
    Resource: Deployment.default.build-code-deployment | ID: BC_K8S_43

How to Fix

apiVersion: v1
kind: Pod
metadata:
  name: <Pod name>
spec:
  containers:
  - name: <container name>
    image: <image>
+   securityContext:

Description

**securityContext** defines privilege and access control settings for your pod or container, and holds security configurations that will be applied to a container. Some fields are present in both **securityContext** and **PodSecurityContext**, when both are set, **securityContext** takes precedence.

Well-defined privilege and access control settings will enhance assurance that your pod is running with the properties it requires to function.

[prisma-cloud-devsecops]

  Memory requests are not set
    Resource: Deployment.default.build-code-deployment | ID: BC_K8S_11

How to Fix

apiVersion: v1
kind: Pod
metadata:
  name: <name>
spec:
  containers:
  - name: <container name>
    image: <image>
    resources:
      requests:
+       memory: <memory request>

Description

Memory resources can be defined using values from bytes to petabytes, it is common to use mebibytes. If you configure a memory request that is larger than the amount of memory on your nodes, the pod will never be scheduled. When specifying a memory request for a container, include the **resources:requests** field in the container’s resource manifest. To specify a memory limit, include **resources:limits**.

Setting memory requests enforces a memory limit for a container. A container is guaranteed to have as much memory as it requests, but is not allowed to use more memory than the limit set. This configuration may save resources and prevent an attack on an exploited container.

[prisma-cloud-devsecops]

  Containers run with AllowPrivilegeEscalation
    Resource: Deployment.default.build-code-deployment | ID: BC_K8S_19

How to Fix

apiVersion: v1
kind: Pod
metadata:
  name: <Pod name>
spec:
  containers:
  - name: <container name>
    image: <image>
    securityContext:
+      allowPrivilegeEscalation: false

Description

The **AllowPrivilegeEscalation** Pod Security Policy controls whether or not a user is allowed to set the security context of a container to **True**. Setting it to **False** ensures that no child process of a container can gain more privileges than its parent.

We recommend you to set AllowPrivilegeEscalation to False, to ensure RunAsUser commands cannot bypass their existing sets of permissions.

Benchmarks

• SOC2 CC6.3.4
• HIPAA 164.312(A)(1) Access control
• CIS KUBERNETES V1.5 1.7.5
• CIS GKE V1.1 4.2.5
• CIS EKS V1.1 4.2.5
• CIS KUBERNETES V1.6 5.2.5

[prisma-cloud-devsecops]

  seccomp is not set to Docker/Default or Runtime/Default
    Resource: Deployment.default.build-code-deployment | ID: BC_K8S_29

How to Fix

apiVersion: v1
kind: Pod
metadata:
  name: <name>
  annotations:
+  	seccomp.security.alpha.kubernetes.io/pod: "docker/default" 
	or
+   seccomp.security.alpha.kubernetes.io/pod: "runtime/default"

Description

Secure computing mode (seccomp) is a Linux kernel feature used to restrict actions available within the container. The seccomp() system call operates on the seccomp state of the calling process. The default seccomp profile provides a reliable setting for running containers with seccomp and disables non-essential system calls.

Benchmarks

• PCI-DSS V3.2 2
• CIS KUBERNETES V1.5 1.6.4
• CIS GKE V1.1 4.6.2
• CIS EKS V1.1 4.6.1
• CIS KUBERNETES V1.6 5.7.2

[prisma-cloud-devsecops]

  Liveness probe is not configured
    Resource: Deployment.default.build-code-deployment | ID: BC_K8S_7

How to Fix

apiVersion: v1
kind: Pod
metadata:
  name: <name>
spec:
  containers:
  - name: <container name>
    image: <image>
+   livenessProbe:
      <Probe arguments>

Description

The kubelet uses liveness probes to know when to schedule restarts for containers. Restarting a container in a deadlock state can help to make the application more available, despite bugs.

If a container is unresponsive, either to a deadlocked application or a multi-threading defect, restarting the container can make the application more available, despite the defect.

[prisma-cloud-devsecops]

  securityContext is not applied to pods and containers
    Resource: Deployment.default.build-code-deployment | ID: BC_K8S_43

How to Fix

apiVersion: v1
kind: Pod
metadata:
  name: <Pod name>
spec:
  containers:
  - name: <container name>
    image: <image>
+   securityContext:

Description

**securityContext** defines privilege and access control settings for your pod or container, and holds security configurations that will be applied to a container. Some fields are present in both **securityContext** and **PodSecurityContext**, when both are set, **securityContext** takes precedence.

Well-defined privilege and access control settings will enhance assurance that your pod is running with the properties it requires to function.

[prisma-cloud-devsecops]

  Read-Only filesystem for containers is not used
    Resource: Deployment.default.build-code-deployment | ID: BC_K8S_21

How to Fix

apiVersion: v1
kind: Pod
metadata:
  name: <Pod name>
spec:
  containers:
  - name: <container name>
    image: <image>
    securityContext:
+      readOnlyRootFilesystem: true

Description

A read-only root filesystem helps to enforce an immutable infrastructure strategy. The container should only write on mounted volumes that can persist, even if the container exits.

Using an immutable root filesystem and a verified boot mechanism prevents against attackers from "owning" the machine through permanent local changes. An immutable root filesystem can also prevent malicious binaries from writing to the host system.

[prisma-cloud-devsecops]

  Image tag is not set to Fixed
    Resource: Deployment.default.build-code-deployment | ID: BC_K8S_13

How to Fix

apiVersion: v1
kind: Pod
metadata:
  name: <name>
spec:
  containers:
  - name: <container name>
+   image: <image>:<image version>
-   image: <image>
-   image: <image>:latest

Description

You can add a **:fixed** tag to a container image, making it easier to determine what it contains, for example to specify the version. Container image tags and digests are used to refer to a specific version or instance of a container image.

We recommend you avoid using the :latest and :blank tags when deploying containers in production as it is harder to track which version of the image is running, and more difficult to roll back properly.

[prisma-cloud-devsecops]

  Service account tokens are not mounted where necessary
    Resource: Deployment.default.build-code-deployment | ID: BC_K8S_35

How to Fix

apiVersion: v1
kind: Pod
metadata:
  name: <name>
spec:
+  automountServiceAccountToken: false

Description

One way to authenticate the API is by using the Service Account token. **ServiceAccount** is an object managed by Kubernetes and used to provide an identity for processes that run in a pod. Every service account has a secret related to it, this secret contains a bearer token. This is a JSON Web Token (JWT), a method for representing claims securely between two parties.

This Service Account token is being used during the authentication stage and can become useful for attackers if the service account is privileged and they have access to such a token. With this token an attacker can easily impersonate the service account and use REST APIs.

Benchmarks

• CIS GKE V1.1 4.1.6
• CIS EKS V1.1 4.1.6
• CIS KUBERNETES V1.6 5.1.6

[prisma-cloud-devsecops]

  Service account tokens are not mounted where necessary
    Resource: Deployment.default.build-code-deployment | ID: BC_K8S_35

How to Fix

apiVersion: v1
kind: Pod
metadata:
  name: <name>
spec:
+  automountServiceAccountToken: false

Description

One way to authenticate the API is by using the Service Account token. **ServiceAccount** is an object managed by Kubernetes and used to provide an identity for processes that run in a pod. Every service account has a secret related to it, this secret contains a bearer token. This is a JSON Web Token (JWT), a method for representing claims securely between two parties.

This Service Account token is being used during the authentication stage and can become useful for attackers if the service account is privileged and they have access to such a token. With this token an attacker can easily impersonate the service account and use REST APIs.

Benchmarks

• CIS GKE V1.1 4.1.6
• CIS EKS V1.1 4.1.6
• CIS KUBERNETES V1.6 5.1.6

[prisma-cloud-devsecops]

  Admission of containers with capabilities assigned is not limited
    Resource: Deployment.default.build-code-deployment | ID: BC_K8S_34

How to Fix

apiVersion: v1
kind: Pod
metadata:
  name: <Pod name>
spec:
  containers:
  - name: <container name>
    image: <image>
    securityContext:
      capabilities:
		drop:
+         - ALL

Description

Docker has a default list of capabilities that are allowed for each container of a pod. The containers use the capabilities from this default list, but pod manifest authors can alter it by requesting additional capabilities, or dropping some of the default capabilities.

Limiting the admission of containers with capabilities ensures that only a small number of containers have extended capabilities outside the default range. This helps ensure that if a container becomes compromised it is unable to provide a productive path for an attacker to move laterally to other containers in the pod.

Benchmarks

• SOC2 CC6.3.4
• CIS KUBERNETES V1.5 1.7.7
• CIS GKE V1.1 4.2.9
• CIS EKS V1.1 4.2.9
• CIS KUBERNETES V1.6 5.2.9

[prisma-cloud-devsecops]

  Readiness probe is not configured
    Resource: Deployment.default.build-code-deployment | ID: BC_K8S_8

How to Fix

apiVersion: v1
kind: Pod
metadata:
  name: <name>
spec:
  containers:
  - name: <container name>
    image: <image>
+   readinessProbe:
      <Probe configurations>

Description

Readiness Probe is a Kubernetes capability that enables teams to make their applications more reliable and robust. This probe regulates under what circumstances the pod should be taken out of the list of service endpoints so that it no longer responds to requests. In defined circumstances the probe can remove the pod from the list of available service endpoints.

Using the Readiness Probe ensures teams define what actions need to be taken to prevent failure and ensure recovery in case of unexpected errors.

Kubernetes.io Documentation

[prisma-cloud-devsecops]

  Images are not selected using a digest
    Resource: Deployment.default.build-code-deployment | ID: BC_K8S_39

How to Fix

apiVersion: v1
kind: Pod
metadata:
  name: <Pod name>
spec:
  containers:
  - name: <container name>
    image: image@sha256:45b23dee08af5e43a7fea6c4cf9c25ccf269ee113168c19722f87876677c5cb2

Description

In some cases you may prefer to use a fixed version of an image, rather than update to newer versions. Docker enables you to pull an image by its digest, specifying exactly which version of an image to pull.

Pulling using a digest allows you to “pin” an image to that version, and guarantee that the image you’re using is always the same. Digests also prevent race-conditions; if a new image is pushed while a deploy is in progress, different nodes may be pulling the images at different times, so some nodes have the new image, and some have the old one. Services automatically resolve tags to digests, so you don't need to manually specify a digest.

[prisma-cloud-devsecops]

  securityContext is not applied to pods and containers
    Resource: Deployment.default.build-code-deployment | ID: BC_K8S_43

How to Fix

apiVersion: v1
kind: Pod
metadata:
  name: <Pod name>
spec:
  containers:
  - name: <container name>
    image: <image>
+   securityContext:

Description

**securityContext** defines privilege and access control settings for your pod or container, and holds security configurations that will be applied to a container. Some fields are present in both **securityContext** and **PodSecurityContext**, when both are set, **securityContext** takes precedence.

Well-defined privilege and access control settings will enhance assurance that your pod is running with the properties it requires to function.

[prisma-cloud-devsecops]

  Admission of containers with capabilities assigned is not limited
    Resource: Deployment.default.build-code-deployment | ID: BC_K8S_34

How to Fix

apiVersion: v1
kind: Pod
metadata:
  name: <Pod name>
spec:
  containers:
  - name: <container name>
    image: <image>
    securityContext:
      capabilities:
		drop:
+         - ALL

Description

Docker has a default list of capabilities that are allowed for each container of a pod. The containers use the capabilities from this default list, but pod manifest authors can alter it by requesting additional capabilities, or dropping some of the default capabilities.

Limiting the admission of containers with capabilities ensures that only a small number of containers have extended capabilities outside the default range. This helps ensure that if a container becomes compromised it is unable to provide a productive path for an attacker to move laterally to other containers in the pod.

Benchmarks

• SOC2 CC6.3.4
• CIS KUBERNETES V1.5 1.7.7
• CIS GKE V1.1 4.2.9
• CIS EKS V1.1 4.2.9
• CIS KUBERNETES V1.6 5.2.9

[prisma-cloud-devsecops]

  Readiness probe is not configured
    Resource: Deployment.default.build-code-deployment | ID: BC_K8S_8

How to Fix

apiVersion: v1
kind: Pod
metadata:
  name: <name>
spec:
  containers:
  - name: <container name>
    image: <image>
+   readinessProbe:
      <Probe configurations>

Description

Readiness Probe is a Kubernetes capability that enables teams to make their applications more reliable and robust. This probe regulates under what circumstances the pod should be taken out of the list of service endpoints so that it no longer responds to requests. In defined circumstances the probe can remove the pod from the list of available service endpoints.

Using the Readiness Probe ensures teams define what actions need to be taken to prevent failure and ensure recovery in case of unexpected errors.

Kubernetes.io Documentation

[prisma-cloud-devsecops]

  Memory requests are not set
    Resource: Deployment.default.build-code-deployment | ID: BC_K8S_11

How to Fix

apiVersion: v1
kind: Pod
metadata:
  name: <name>
spec:
  containers:
  - name: <container name>
    image: <image>
    resources:
      requests:
+       memory: <memory request>

Description

Memory resources can be defined using values from bytes to petabytes, it is common to use mebibytes. If you configure a memory request that is larger than the amount of memory on your nodes, the pod will never be scheduled. When specifying a memory request for a container, include the **resources:requests** field in the container’s resource manifest. To specify a memory limit, include **resources:limits**.

Setting memory requests enforces a memory limit for a container. A container is guaranteed to have as much memory as it requests, but is not allowed to use more memory than the limit set. This configuration may save resources and prevent an attack on an exploited container.

[prisma-cloud-devsecops]

  Images are not selected using a digest
    Resource: Deployment.default.build-code-deployment | ID: BC_K8S_39

How to Fix

apiVersion: v1
kind: Pod
metadata:
  name: <Pod name>
spec:
  containers:
  - name: <container name>
    image: image@sha256:45b23dee08af5e43a7fea6c4cf9c25ccf269ee113168c19722f87876677c5cb2

Description

In some cases you may prefer to use a fixed version of an image, rather than update to newer versions. Docker enables you to pull an image by its digest, specifying exactly which version of an image to pull.

Pulling using a digest allows you to “pin” an image to that version, and guarantee that the image you’re using is always the same. Digests also prevent race-conditions; if a new image is pushed while a deploy is in progress, different nodes may be pulling the images at different times, so some nodes have the new image, and some have the old one. Services automatically resolve tags to digests, so you don't need to manually specify a digest.

[prisma-cloud-devsecops]

  seccomp is not set to Docker/Default or Runtime/Default
    Resource: Deployment.default.build-code-deployment | ID: BC_K8S_29

How to Fix

apiVersion: v1
kind: Pod
metadata:
  name: <name>
  annotations:
+  	seccomp.security.alpha.kubernetes.io/pod: "docker/default" 
	or
+   seccomp.security.alpha.kubernetes.io/pod: "runtime/default"

Description

Secure computing mode (seccomp) is a Linux kernel feature used to restrict actions available within the container. The seccomp() system call operates on the seccomp state of the calling process. The default seccomp profile provides a reliable setting for running containers with seccomp and disables non-essential system calls.

Benchmarks

• PCI-DSS V3.2 2
• CIS KUBERNETES V1.5 1.6.4
• CIS GKE V1.1 4.6.2
• CIS EKS V1.1 4.6.1
• CIS KUBERNETES V1.6 5.7.2

[prisma-cloud-devsecops]

  Containers do not run with a high UID
    Resource: Deployment.default.build-code-deployment | ID: BC_K8S_37

How to Fix

apiVersion: v1
kind: Pod
metadata:
  name: <name>
spec:
	securityContext:
+ 	runAsUser: <UID higher then 10000>

Description

Linux namespaces provide isolation for running processes and limits access to system resources. To prevent privilege-escalation attacks from within a container, we recommend that you configure your container’s applications to run as unprivileged users. The mapped user is assigned a range of UIDs which function within the namespace as normal UIDs from 0 to 65536, but have no privileges on the host machine itself.

If a process attempts to escalate privilege outside of the namespace, the process is running as an unprivileged high-number UID on the host, not mapped to a real user. This means the process has no privileges on the host system and cannot be attacked by this method.

This check will trigger below UID 10,000 as common linux distributions will assign UID 1000 to the first non-root, non system user and 1000 users should provide a reasonable buffer.

[prisma-cloud-devsecops]

  Admission of root containers not minimized
    Resource: Deployment.default.build-code-deployment | ID: BC_K8S_22

How to Fix

apiVersion: v1
kind: Pod
metadata:
  name: <name>
spec:
	securityContext:
+ 	runAsNonRoot: true
+ 	runAsUser: <specific user>

Description

Containers rely on the traditional Unix security model granting explicit and implicit permissions to resources, through permissions granted to users and groups. User namespaces are not enabled in Kubernetes. The container's user ID table maps to the host's user table, and running a process as the root user inside a container runs it as root on the host. Although possible, we do not recommend running as root inside the container.

Containers that run as root usually have far more permissions than their workload requires. In case of compromise, an attacker can use these permissions to further an attack on the network. Several container images use the root user to run PID 1. An attacker will have root permissions in the container and be able to exploit mis-configurations.

Benchmarks

• SOC2 CC6.3.4
• HIPAA 164.312(A)(1) Access control
• CIS KUBERNETES V1.5 1.7.6
• CIS GKE V1.1 4.2.6
• CIS EKS V1.1 4.2.6
• CIS KUBERNETES V1.6 5.2.6

[prisma-cloud-devsecops]

  securityContext is not applied to pods and containers
    Resource: Deployment.default.build-code-deployment | ID: BC_K8S_43

How to Fix

apiVersion: v1
kind: Pod
metadata:
  name: <Pod name>
spec:
  containers:
  - name: <container name>
    image: <image>
+   securityContext:

Description

**securityContext** defines privilege and access control settings for your pod or container, and holds security configurations that will be applied to a container. Some fields are present in both **securityContext** and **PodSecurityContext**, when both are set, **securityContext** takes precedence.

Well-defined privilege and access control settings will enhance assurance that your pod is running with the properties it requires to function.

[prisma-cloud-devsecops]

  Service account tokens are not mounted where necessary
    Resource: Deployment.default.build-code-deployment | ID: BC_K8S_35

How to Fix

apiVersion: v1
kind: Pod
metadata:
  name: <name>
spec:
+  automountServiceAccountToken: false

Description

One way to authenticate the API is by using the Service Account token. **ServiceAccount** is an object managed by Kubernetes and used to provide an identity for processes that run in a pod. Every service account has a secret related to it, this secret contains a bearer token. This is a JSON Web Token (JWT), a method for representing claims securely between two parties.

This Service Account token is being used during the authentication stage and can become useful for attackers if the service account is privileged and they have access to such a token. With this token an attacker can easily impersonate the service account and use REST APIs.

Benchmarks

• CIS GKE V1.1 4.1.6
• CIS EKS V1.1 4.1.6
• CIS KUBERNETES V1.6 5.1.6

[prisma-cloud-devsecops]

  Containers run with AllowPrivilegeEscalation
    Resource: Deployment.default.build-code-deployment | ID: BC_K8S_19

How to Fix

apiVersion: v1
kind: Pod
metadata:
  name: <Pod name>
spec:
  containers:
  - name: <container name>
    image: <image>
    securityContext:
+      allowPrivilegeEscalation: false

Description

The **AllowPrivilegeEscalation** Pod Security Policy controls whether or not a user is allowed to set the security context of a container to **True**. Setting it to **False** ensures that no child process of a container can gain more privileges than its parent.

We recommend you to set AllowPrivilegeEscalation to False, to ensure RunAsUser commands cannot bypass their existing sets of permissions.

Benchmarks

• SOC2 CC6.3.4
• HIPAA 164.312(A)(1) Access control
• CIS KUBERNETES V1.5 1.7.5
• CIS GKE V1.1 4.2.5
• CIS EKS V1.1 4.2.5
• CIS KUBERNETES V1.6 5.2.5

[prisma-cloud-devsecops]

  Default namespace is used
    Resource: Service.default.build-code-service | ID: BC_K8S_20

How to Fix

apiVersion: <apiVersion>
kind: <kind>
metadata:
  name: <name>
+ namespace: <your namespace>
- namespace: default

Description

In Kubernetes, the cluster comes out of the box with a namespace called “default.” Other namespaces Kubernetes includes are: default, kube-system and kube-public. Some Kubernetes tooling is set up out of the box to use this namespace and you can’t delete it.

We recommend that you do not use the default namespace in large production systems. Using this space can result in accidental disruption with other services. Instead, we recommend you create alternate namespaces and use them to run additional required services.

Benchmarks

• PCI-DSS V3.2 2
• CIS KUBERNETES V1.5 1.6.2

[prisma-cloud-devsecops]

  securityContext is not applied to pods and containers
    Resource: Deployment.default.build-code-deployment | ID: BC_K8S_28

How to Fix

apiVersion: v1
kind: Pod
metadata:
  name: <Pod name>
spec:
  containers:
  - name: <container name>
    image: <image>
+   securityContext:

Description

**securityContext** defines privilege and access control settings for your pod or container, and holds security configurations that will be applied to a container. Some fields are present in both **securityContext** and **PodSecurityContext**, when both are set, **securityContext** takes precedence.

Well-defined privilege and access control settings will enhance assurance that your pod is running with the properties it requires to function.

Benchmarks

• CIS KUBERNETES V1.5 1.6.5
• CIS GKE V1.1 4.6.3
• CIS EKS V1.1 4.6.2
• CIS KUBERNETES V1.6 5.7.3

[prisma-cloud-devsecops]

  Containers run with AllowPrivilegeEscalation
    Resource: Deployment.default.build-code-deployment | ID: BC_K8S_19

How to Fix

apiVersion: v1
kind: Pod
metadata:
  name: <Pod name>
spec:
  containers:
  - name: <container name>
    image: <image>
    securityContext:
+      allowPrivilegeEscalation: false

Description

The **AllowPrivilegeEscalation** Pod Security Policy controls whether or not a user is allowed to set the security context of a container to **True**. Setting it to **False** ensures that no child process of a container can gain more privileges than its parent.

We recommend you to set AllowPrivilegeEscalation to False, to ensure RunAsUser commands cannot bypass their existing sets of permissions.

Benchmarks

• SOC2 CC6.3.4
• HIPAA 164.312(A)(1) Access control
• CIS KUBERNETES V1.5 1.7.5
• CIS GKE V1.1 4.2.5
• CIS EKS V1.1 4.2.5
• CIS KUBERNETES V1.6 5.2.5

[prisma-cloud-devsecops]

  Read-Only filesystem for containers is not used
    Resource: Deployment.default.build-code-deployment | ID: BC_K8S_21

How to Fix

apiVersion: v1
kind: Pod
metadata:
  name: <Pod name>
spec:
  containers:
  - name: <container name>
    image: <image>
    securityContext:
+      readOnlyRootFilesystem: true

Description

A read-only root filesystem helps to enforce an immutable infrastructure strategy. The container should only write on mounted volumes that can persist, even if the container exits.

Using an immutable root filesystem and a verified boot mechanism prevents against attackers from "owning" the machine through permanent local changes. An immutable root filesystem can also prevent malicious binaries from writing to the host system.

[prisma-cloud-devsecops]

  Containers do not run with a high UID
    Resource: Deployment.default.build-code-deployment | ID: BC_K8S_37

How to Fix

apiVersion: v1
kind: Pod
metadata:
  name: <name>
spec:
	securityContext:
+ 	runAsUser: <UID higher then 10000>

Description

Linux namespaces provide isolation for running processes and limits access to system resources. To prevent privilege-escalation attacks from within a container, we recommend that you configure your container’s applications to run as unprivileged users. The mapped user is assigned a range of UIDs which function within the namespace as normal UIDs from 0 to 65536, but have no privileges on the host machine itself.

If a process attempts to escalate privilege outside of the namespace, the process is running as an unprivileged high-number UID on the host, not mapped to a real user. This means the process has no privileges on the host system and cannot be attacked by this method.

This check will trigger below UID 10,000 as common linux distributions will assign UID 1000 to the first non-root, non system user and 1000 users should provide a reasonable buffer.

[prisma-cloud-devsecops]

  Admission of containers with capabilities assigned is not limited
    Resource: Deployment.default.build-code-deployment | ID: BC_K8S_34

How to Fix

apiVersion: v1
kind: Pod
metadata:
  name: <Pod name>
spec:
  containers:
  - name: <container name>
    image: <image>
    securityContext:
      capabilities:
		drop:
+         - ALL

Description

Docker has a default list of capabilities that are allowed for each container of a pod. The containers use the capabilities from this default list, but pod manifest authors can alter it by requesting additional capabilities, or dropping some of the default capabilities.

Limiting the admission of containers with capabilities ensures that only a small number of containers have extended capabilities outside the default range. This helps ensure that if a container becomes compromised it is unable to provide a productive path for an attacker to move laterally to other containers in the pod.

Benchmarks

• SOC2 CC6.3.4
• CIS KUBERNETES V1.5 1.7.7
• CIS GKE V1.1 4.2.9
• CIS EKS V1.1 4.2.9
• CIS KUBERNETES V1.6 5.2.9

[prisma-cloud-devsecops]

  Default namespace is used
    Resource: Service.default.build-code-service | ID: BC_K8S_20

How to Fix

apiVersion: <apiVersion>
kind: <kind>
metadata:
  name: <name>
+ namespace: <your namespace>
- namespace: default

Description

In Kubernetes, the cluster comes out of the box with a namespace called “default.” Other namespaces Kubernetes includes are: default, kube-system and kube-public. Some Kubernetes tooling is set up out of the box to use this namespace and you can’t delete it.

We recommend that you do not use the default namespace in large production systems. Using this space can result in accidental disruption with other services. Instead, we recommend you create alternate namespaces and use them to run additional required services.

Benchmarks

• PCI-DSS V3.2 2
• CIS KUBERNETES V1.5 1.6.2

[prisma-cloud-devsecops]

  Service account tokens are not mounted where necessary
    Resource: Deployment.default.build-code-deployment | ID: BC_K8S_35

How to Fix

apiVersion: v1
kind: Pod
metadata:
  name: <name>
spec:
+  automountServiceAccountToken: false

Description

One way to authenticate the API is by using the Service Account token. **ServiceAccount** is an object managed by Kubernetes and used to provide an identity for processes that run in a pod. Every service account has a secret related to it, this secret contains a bearer token. This is a JSON Web Token (JWT), a method for representing claims securely between two parties.

This Service Account token is being used during the authentication stage and can become useful for attackers if the service account is privileged and they have access to such a token. With this token an attacker can easily impersonate the service account and use REST APIs.

Benchmarks

• CIS GKE V1.1 4.1.6
• CIS EKS V1.1 4.1.6
• CIS KUBERNETES V1.6 5.1.6

[prisma-cloud-devsecops]

  CPU request is not set
    Resource: Deployment.default.build-code-deployment | ID: BC_K8S_9

How to Fix

apiVersion: v1
kind: Pod
metadata:
  name: <name>
spec:
  containers:
  - name: <container name>
    image: <image>
    resources:
      requests:
+       cpu: <cpu request>

Description

When specifying the resource request for containers in a pod, the scheduler uses this information to decide which node to place the pod on. When setting resource limit for a container, the kubelet enforces those limits so that the running container is not allowed to use more of that resource than the limit you set.

If a container is created in a namespace that has a default CPU limit, and the container does not specify its own CPU limit, then the container is assigned the default CPU limit. Kubernetes assigns a default CPU request under certain conditions.

[prisma-cloud-devsecops]

  Default namespace is used
    Resource: Deployment.default.build-code-deployment | ID: BC_K8S_20

How to Fix

apiVersion: <apiVersion>
kind: <kind>
metadata:
  name: <name>
+ namespace: <your namespace>
- namespace: default

Description

In Kubernetes, the cluster comes out of the box with a namespace called “default.” Other namespaces Kubernetes includes are: default, kube-system and kube-public. Some Kubernetes tooling is set up out of the box to use this namespace and you can’t delete it.

We recommend that you do not use the default namespace in large production systems. Using this space can result in accidental disruption with other services. Instead, we recommend you create alternate namespaces and use them to run additional required services.

Benchmarks

• PCI-DSS V3.2 2
• CIS KUBERNETES V1.5 1.6.2

[prisma-cloud-devsecops]

  Image tag is not set to Fixed
    Resource: Deployment.default.build-code-deployment | ID: BC_K8S_13

How to Fix

apiVersion: v1
kind: Pod
metadata:
  name: <name>
spec:
  containers:
  - name: <container name>
+   image: <image>:<image version>
-   image: <image>
-   image: <image>:latest

Description

You can add a **:fixed** tag to a container image, making it easier to determine what it contains, for example to specify the version. Container image tags and digests are used to refer to a specific version or instance of a container image.

We recommend you avoid using the :latest and :blank tags when deploying containers in production as it is harder to track which version of the image is running, and more difficult to roll back properly.

[prisma-cloud-devsecops]

  seccomp is not set to Docker/Default or Runtime/Default
    Resource: Deployment.default.build-code-deployment | ID: BC_K8S_29

How to Fix

apiVersion: v1
kind: Pod
metadata:
  name: <name>
  annotations:
+  	seccomp.security.alpha.kubernetes.io/pod: "docker/default" 
	or
+   seccomp.security.alpha.kubernetes.io/pod: "runtime/default"

Description

Secure computing mode (seccomp) is a Linux kernel feature used to restrict actions available within the container. The seccomp() system call operates on the seccomp state of the calling process. The default seccomp profile provides a reliable setting for running containers with seccomp and disables non-essential system calls.

Benchmarks

• PCI-DSS V3.2 2
• CIS KUBERNETES V1.5 1.6.4
• CIS GKE V1.1 4.6.2
• CIS EKS V1.1 4.6.1
• CIS KUBERNETES V1.6 5.7.2

[prisma-cloud-devsecops]

  Admission of root containers not minimized
    Resource: Deployment.default.build-code-deployment | ID: BC_K8S_22

How to Fix

apiVersion: v1
kind: Pod
metadata:
  name: <name>
spec:
	securityContext:
+ 	runAsNonRoot: true
+ 	runAsUser: <specific user>

Description

Containers rely on the traditional Unix security model granting explicit and implicit permissions to resources, through permissions granted to users and groups. User namespaces are not enabled in Kubernetes. The container's user ID table maps to the host's user table, and running a process as the root user inside a container runs it as root on the host. Although possible, we do not recommend running as root inside the container.

Containers that run as root usually have far more permissions than their workload requires. In case of compromise, an attacker can use these permissions to further an attack on the network. Several container images use the root user to run PID 1. An attacker will have root permissions in the container and be able to exploit mis-configurations.

Benchmarks

• SOC2 CC6.3.4
• HIPAA 164.312(A)(1) Access control
• CIS KUBERNETES V1.5 1.7.6
• CIS GKE V1.1 4.2.6
• CIS EKS V1.1 4.2.6
• CIS KUBERNETES V1.6 5.2.6

[prisma-cloud-devsecops]

  Admission of containers with NET_RAW capability is not minimized
    Resource: Deployment.default.build-code-deployment | ID: BC_K8S_27

How to Fix

apiVersion: v1
kind: Pod
metadata:
  name: <Pod name>
spec:
  containers:
  - name: <container name>
    image: <image>
    securityContext:
      capabilities:
		drop:
+        - NET_RAW
+        - ALL

Description

NET_RAW capability allows the binary to use RAW and PACKET sockets as well as binding to any address for transparent proxying. The *ep* stands for “effective” (active) and “permitted” (allowed to be used).

With Docker as the container runtime NET_RAW capability is enabled by default and may be misused by malicious containers. We recommend you define at least one PodSecurityPolicy (PSP) to prevent containers with NET_RAW capability from launching.

Benchmarks

• SOC2 CC6.3.4
• CIS KUBERNETES V1.5 1.7.7
• CIS GKE V1.1 4.2.7
• CIS EKS V1.1 4.2.7
• CIS KUBERNETES V1.6 5.2.7

[prisma-cloud-devsecops]

  Liveness probe is not configured
    Resource: Deployment.default.build-code-deployment | ID: BC_K8S_7

How to Fix

apiVersion: v1
kind: Pod
metadata:
  name: <name>
spec:
  containers:
  - name: <container name>
    image: <image>
+   livenessProbe:
      <Probe arguments>

Description

The kubelet uses liveness probes to know when to schedule restarts for containers. Restarting a container in a deadlock state can help to make the application more available, despite bugs.

If a container is unresponsive, either to a deadlocked application or a multi-threading defect, restarting the container can make the application more available, despite the defect.

[prisma-cloud-devsecops]

  Memory requests are not set
    Resource: Deployment.default.build-code-deployment | ID: BC_K8S_11

How to Fix

apiVersion: v1
kind: Pod
metadata:
  name: <name>
spec:
  containers:
  - name: <container name>
    image: <image>
    resources:
      requests:
+       memory: <memory request>

Description

Memory resources can be defined using values from bytes to petabytes, it is common to use mebibytes. If you configure a memory request that is larger than the amount of memory on your nodes, the pod will never be scheduled. When specifying a memory request for a container, include the **resources:requests** field in the container’s resource manifest. To specify a memory limit, include **resources:limits**.

Setting memory requests enforces a memory limit for a container. A container is guaranteed to have as much memory as it requests, but is not allowed to use more memory than the limit set. This configuration may save resources and prevent an attack on an exploited container.

[prisma-cloud-devsecops]

  Images are not selected using a digest
    Resource: Deployment.default.build-code-deployment | ID: BC_K8S_39

How to Fix

apiVersion: v1
kind: Pod
metadata:
  name: <Pod name>
spec:
  containers:
  - name: <container name>
    image: image@sha256:45b23dee08af5e43a7fea6c4cf9c25ccf269ee113168c19722f87876677c5cb2

Description

In some cases you may prefer to use a fixed version of an image, rather than update to newer versions. Docker enables you to pull an image by its digest, specifying exactly which version of an image to pull.

Pulling using a digest allows you to “pin” an image to that version, and guarantee that the image you’re using is always the same. Digests also prevent race-conditions; if a new image is pushed while a deploy is in progress, different nodes may be pulling the images at different times, so some nodes have the new image, and some have the old one. Services automatically resolve tags to digests, so you don't need to manually specify a digest.

[prisma-cloud-devsecops]

  Readiness probe is not configured
    Resource: Deployment.default.build-code-deployment | ID: BC_K8S_8

How to Fix

apiVersion: v1
kind: Pod
metadata:
  name: <name>
spec:
  containers:
  - name: <container name>
    image: <image>
+   readinessProbe:
      <Probe configurations>

Description

Readiness Probe is a Kubernetes capability that enables teams to make their applications more reliable and robust. This probe regulates under what circumstances the pod should be taken out of the list of service endpoints so that it no longer responds to requests. In defined circumstances the probe can remove the pod from the list of available service endpoints.

Using the Readiness Probe ensures teams define what actions need to be taken to prevent failure and ensure recovery in case of unexpected errors.

Kubernetes.io Documentation

[prisma-cloud-devsecops]

  Read-Only filesystem for containers is not used
    Resource: Deployment.default.build-code-deployment | ID: BC_K8S_21

How to Fix

apiVersion: v1
kind: Pod
metadata:
  name: <Pod name>
spec:
  containers:
  - name: <container name>
    image: <image>
    securityContext:
+      readOnlyRootFilesystem: true

Description

A read-only root filesystem helps to enforce an immutable infrastructure strategy. The container should only write on mounted volumes that can persist, even if the container exits.

Using an immutable root filesystem and a verified boot mechanism prevents against attackers from "owning" the machine through permanent local changes. An immutable root filesystem can also prevent malicious binaries from writing to the host system.