Create deployment.yaml

[mikeurbanski1]

No description provided.

[bridgecrew]

Bridgecrew has found 16 infrastructure configuration errors in this PR ⬇️

[bridgecrew]

  Apply security context to your pods and containers
    Resource: Deployment.kubernetes-goat-home-deployment.default | 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.

[bridgecrew]

  Minimize the admission of root containers
    Resource: Deployment.kubernetes-goat-home-deployment.default | 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

[bridgecrew]

  Containers should run as a high UID to avoid host conflict
    Resource: Deployment.kubernetes-goat-home-deployment.default | 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.

[bridgecrew]

  Ensure that the seccomp profile is set to docker/default or runtime/default
    Resource: Deployment.kubernetes-goat-home-deployment.default | 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

[bridgecrew]

  Ensure that Service Account Tokens are only mounted where necessary
    Resource: Deployment.kubernetes-goat-home-deployment.default | 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

[bridgecrew]

  Liveness Probe Should be Configured
    Resource: Deployment.kubernetes-goat-home-deployment.default (container 0) - kubernetes-goat-home | 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.

[bridgecrew]

  Memory requests should be set
    Resource: Deployment.kubernetes-goat-home-deployment.default (container 0) - kubernetes-goat-home | 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.

[bridgecrew]

  Minimize the admission of containers with capabilities assigned
    Resource: Deployment.kubernetes-goat-home-deployment.default (container 0) - kubernetes-goat-home | 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

[bridgecrew]

  Use read-only filesystem for containers where possible
    Resource: Deployment.kubernetes-goat-home-deployment.default (container 0) - kubernetes-goat-home | 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.

[bridgecrew]

  Readiness Probe Should be Configured
    Resource: Deployment.kubernetes-goat-home-deployment.default (container 0) - kubernetes-goat-home | 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