Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Create deployment.yaml #3

Open
wants to merge 1 commit into
base: master
Choose a base branch
from
Open

Create deployment.yaml #3

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
34 changes: 34 additions & 0 deletions deployment.yaml
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,34 @@
apiVersion: apps/v1
Copy link

@bridgecrew bridgecrew bot Jul 20, 2021 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LOW   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.

Copy link

@bridgecrew bridgecrew bot Jul 20, 2021 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

MEDIUM   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

Copy link

@bridgecrew bridgecrew bot Jul 20, 2021 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LOW   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.

Copy link

@bridgecrew bridgecrew bot Jul 20, 2021 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LOW   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

Copy link

@bridgecrew bridgecrew bot Jul 20, 2021 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LOW   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

kind: Deployment
metadata:
name: kubernetes-goat-home-deployment
spec:
selector:
matchLabels:
app: kubernetes-goat-home
template:
metadata:
labels:
app: kubernetes-goat-home
spec:
containers:
- name: kubernetes-goat-home
Copy link

@bridgecrew bridgecrew bot Jul 20, 2021 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

MEDIUM   Containers should not run with allowPrivilegeEscalation
    Resource: Deployment.kubernetes-goat-home-deployment.default (container 0) - kubernetes-goat-home | 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

Copy link

@bridgecrew bridgecrew bot Jul 20, 2021 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link

@bridgecrew bridgecrew bot Jul 20, 2021 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link

@bridgecrew bridgecrew bot Jul 20, 2021 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link

@bridgecrew bridgecrew bot Jul 20, 2021 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LOW   Image should use digest
    Resource: Deployment.kubernetes-goat-home-deployment.default (container 0) - kubernetes-goat-home | 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.

Copy link

@bridgecrew bridgecrew bot Jul 20, 2021 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LOW   Image Tag should be fixed - not latest or blank
    Resource: Deployment.kubernetes-goat-home-deployment.default (container 0) - kubernetes-goat-home | 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.

Copy link

@bridgecrew bridgecrew bot Jul 20, 2021 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LOW   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.

Copy link

@bridgecrew bridgecrew bot Jul 20, 2021 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LOW   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.

Copy link

@bridgecrew bridgecrew bot Jul 20, 2021 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LOW   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

Copy link

@bridgecrew bridgecrew bot Jul 20, 2021 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LOW   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.

Copy link

@bridgecrew bridgecrew bot Jul 20, 2021 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LOW   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

image: madhuakula/k8s-goat-home
resources:
limits:
memory: "50Mi"
cpu: "30m"
ports:
- containerPort: 80
---
apiVersion: v1
kind: Service
metadata:
name: kubernetes-goat-home-service
spec:
ports:
- protocol: TCP
port: 80
targetPort: 80
selector:
app: kubernetes-goat-home