diff --git a/cheatsheets/Docker_Security_Cheat_Sheet.md b/cheatsheets/Docker_Security_Cheat_Sheet.md index 25408cf8d2..43a68b455f 100644 --- a/cheatsheets/Docker_Security_Cheat_Sheet.md +++ b/cheatsheets/Docker_Security_Cheat_Sheet.md @@ -34,42 +34,39 @@ Configuring the container to use an unprivileged user is the best way to prevent 1. During runtime using `-u` option of `docker run` command e.g.: - ```bash - docker run -u 4000 alpine - ``` +```bash +docker run -u 4000 alpine +``` 2. During build time. Simple add user in Dockerfile and use it. For example: - ```docker - FROM alpine - RUN groupadd -r myuser && useradd -r -g myuser myuser - - USER myuser - ``` +```dockerfile +FROM alpine +RUN groupadd -r myuser && useradd -r -g myuser myuser +# +USER myuser +``` 3. Enable user namespace support (`--userns-remap=default`) in [Docker daemon](https://docs.docker.com/engine/security/userns-remap/#enable-userns-remap-on-the-daemon) -More information about this topic can be found at [Docker official documentation](https://docs.docker.com/engine/security/userns-remap/). For additional security, you can also run in rootless mode, which is discussed in [Rule \#12](#rule-12---run-docker-in-root-less-mode). +More information about this topic can be found at [Docker official documentation](https://docs.docker.com/engine/security/userns-remap/). For additional security, you can also run in rootless mode, which is discussed in [Rule \#11](#rule-11---run-docker-in-rootless-mode). -In Kubernetes, this can be configured in [Security Context](https://kubernetes.io/docs/tasks/configure-pod-container/security-context/) using `runAsNonRoot` field e.g.: +In Kubernetes, this can be configured in [Security Context](https://kubernetes.io/docs/tasks/configure-pod-container/security-context/) using the `runAsUser` field with the user ID e.g: ```yaml -kind: ... -apiVersion: ... +apiVersion: v1 +kind: Pod metadata: - name: ... + name: example spec: - ... containers: - - name: ... - image: .... + - name: example + image: gcr.io/google-samples/node-hello:1.0 securityContext: - ... - runAsNonRoot: true - ... + runAsUser: 4000 # <-- This is the pod user ID ``` -As a Kubernetes cluster administrator, you can configure it using [Pod Security Policies](https://kubernetes.io/docs/concepts/policy/pod-security-policy/). +As a Kubernetes cluster administrator, you can configure a hardened default using the [`Restricted` level](https://kubernetes.io/docs/concepts/security/pod-security-standards/#restricted) with built-in [Pod Security admission controller](https://kubernetes.io/docs/concepts/security/pod-security-admission/), if greater customization is desired consider using [Admission Webhooks](https://kubernetes.io/docs/reference/access-authn-authz/extensible-admission-controllers/#what-are-admission-webhooks) or a [third party alternative](https://kubernetes.io/docs/concepts/security/pod-security-standards/#alternatives). ### RULE \#3 - Limit capabilities (Grant only specific capabilities, needed by a container) @@ -85,29 +82,25 @@ docker run --cap-drop all --cap-add CHOWN alpine **And remember: Do not run containers with the *--privileged* flag!!!** -In Kubernetes this can be configured in [Security Context](https://kubernetes.io/docs/tasks/configure-pod-container/security-context/) using `capabilities` field e.g.: +In Kubernetes this can be configured in [Security Context](https://kubernetes.io/docs/tasks/configure-pod-container/security-context/) using `capabilities` field e.g: ```yaml -kind: ... -apiVersion: ... +apiVersion: v1 +kind: Pod metadata: - name: ... + name: example spec: - ... containers: - - name: ... - image: .... + - name: example + image: gcr.io/google-samples/node-hello:1.0 securityContext: - ... capabilities: drop: - - all - add: - - CHOWN - ... + - ALL + add: ["CHOWN"] ``` -As a Kubernetes cluster administrator, you can configure it using [Pod Security Policies](https://kubernetes.io/docs/concepts/policy/pod-security-policy/). +As a Kubernetes cluster administrator, you can configure a hardened default using the [`Restricted` level](https://kubernetes.io/docs/concepts/security/pod-security-standards/#restricted) with built-in [Pod Security admission controller](https://kubernetes.io/docs/concepts/security/pod-security-admission/), if greater customization is desired consider using [Admission Webhooks](https://kubernetes.io/docs/reference/access-authn-authz/extensible-admission-controllers/#what-are-admission-webhooks) or a [third party alternative](https://kubernetes.io/docs/concepts/security/pod-security-standards/#alternatives). ### RULE \#4 - Prevent in-container privilege escalation @@ -116,26 +109,23 @@ Always run your docker images with `--security-opt=no-new-privileges` in order t In Kubernetes, this can be configured in [Security Context](https://kubernetes.io/docs/tasks/configure-pod-container/security-context/) using `allowPrivilegeEscalation` field e.g.: ```yaml -kind: ... -apiVersion: ... +apiVersion: v1 +kind: Pod metadata: - name: ... + name: example spec: - ... containers: - - name: ... - image: .... + - name: example + image: gcr.io/google-samples/node-hello:1.0 securityContext: - ... - allowPrivilegeEscalation: false - ... + allowPrivilegeEscalation: false ``` -As a Kubernetes cluster administrator, you can refer to Kubernetes documentation to configure it using [Pod Security Policies](https://kubernetes.io/docs/concepts/policy/pod-security-policy/). +As a Kubernetes cluster administrator, you can configure a hardened default using the [`Restricted` level](https://kubernetes.io/docs/concepts/security/pod-security-standards/#restricted) with built-in [Pod Security admission controller](https://kubernetes.io/docs/concepts/security/pod-security-admission/), if greater customization is desired consider using [Admission Webhooks](https://kubernetes.io/docs/reference/access-authn-authz/extensible-admission-controllers/#what-are-admission-webhooks) or a [third party alternative](https://kubernetes.io/docs/concepts/security/pod-security-standards/#alternatives). ### RULE \#5 - Be mindful of Inter-Container Connectivity -Inter-Container Connectivity (icc) is enabled by default, allowing all containers to communicate with each other through the [`docker0` bridged network](https://docs.docker.com/network/drivers/bridge/). Instead of using the --icc=false flag with the Docker daemon, which completely disables inter-container communication, consider defining specific network configurations. This can be achieved by creating custom Docker networks and specifying which containers should be attached to them. This method provides more granular control over container communication. +Inter-Container Connectivity (icc) is enabled by default, allowing all containers to communicate with each other through the [`docker0` bridged network](https://docs.docker.com/network/drivers/bridge/). Instead of using the `--icc=false` flag with the Docker daemon, which completely disables inter-container communication, consider defining specific network configurations. This can be achieved by creating custom Docker networks and specifying which containers should be attached to them. This method provides more granular control over container communication. For detailed guidance on configuring Docker networks for container communication, refer to the [Docker Documentation](https://docs.docker.com/network/#communication-between-containers). @@ -147,7 +137,7 @@ In Kubernetes environments, [Network Policies](https://kubernetes.io/docs/concep Consider using security profile like [seccomp](https://docs.docker.com/engine/security/seccomp/) or [AppArmor](https://docs.docker.com/engine/security/apparmor/). -Instructions how to do this inside Kubernetes can be found at [Security Context documentation](https://kubernetes.io/docs/tasks/configure-pod-container/security-context/) and in [Kubernetes API documentation](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.18/#securitycontext-v1-core) +Instructions how to do this inside Kubernetes can be found at [Configure a Security Context for a Pod or Container](https://kubernetes.io/docs/tutorials/security/seccomp/). ### RULE \#7 - Limit resources (memory, CPU, file descriptors, processes, restarts) @@ -181,22 +171,19 @@ services: read_only: true ``` -Equivalent in Kubernetes in [Security Context](https://kubernetes.io/docs/tasks/configure-pod-container/security-context/) will be: +Equivalent in Kubernetes in [Security Context](https://kubernetes.io/docs/tasks/configure-pod-container/security-context/): ```yaml -kind: ... -apiVersion: ... +apiVersion: v1 +kind: Pod metadata: - name: ... + name: example spec: - ... containers: - - name: ... - image: .... + - name: example + image: gcr.io/google-samples/node-hello:1.0 securityContext: - ... - readOnlyRootFilesystem: true - ... + readOnlyRootFilesystem: true ``` In addition, if the volume is mounted only for reading **mount them as a read-only** diff --git a/cheatsheets/Kubernetes_Security_Cheat_Sheet.md b/cheatsheets/Kubernetes_Security_Cheat_Sheet.md index 60747e5651..d2b1e1e0a6 100644 --- a/cheatsheets/Kubernetes_Security_Cheat_Sheet.md +++ b/cheatsheets/Kubernetes_Security_Cheat_Sheet.md @@ -253,7 +253,7 @@ Downloading and running CIs from unknown sources is very dangerous. Make sure th -- -### Use A CI Pipeline To Control and Identify Vunlerabilities +### Use A CI Pipeline To Control and Identify Vulnerabilities The Kubernetes container registry serves as a central repository of all container images in the system. Depending on your needs, you can utilize a public repository or have a private repository as the container registry. We recommend that you store your approved images in a private registry and only push approved images to these registries, which automatically reduces the number of potential images that enter your pipeline down to a fraction of the hundreds of thousands of publicly available images. @@ -344,7 +344,7 @@ Learn more about webhook at readOnlyRootFilesystem Description: Controls whether a container will be able to write into the root filesystem. -4. Security Conext Setting: PodSecurityContext->runAsNonRoot +4. Security Context Setting: PodSecurityContext->runAsNonRoot Description: Prevents running a container with 'root' user as part of the pod | #### Security context example: A pod definition that includes security context parameters @@ -431,7 +431,7 @@ It provides security features which quickly identify any compromising traffic th 3. Ability to secure microservices with mTLS -Since securing microservices is hard, there are many tools that address microservices security. Howver, the service mesh is the most elegant solution for addressing encryption of on-the-wire traffic within the network. +Since securing microservices is hard, there are many tools that address microservices security. However, the service mesh is the most elegant solution for addressing encryption of on-the-wire traffic within the network. It provides defense with mutual TLS (mTLS) encryption of the traffic between your services, and the mesh can automatically encrypt and decrypt requests and responses, which removes that burden from application developers. The mesh can also improve performance by prioritizing the reuse of existing, persistent connections, which reduces the need for the computationally expensive creation of new ones. With service mesh, you can secure traffic over the wire and also make strong identity-based authentication and authorizations for each microservice. @@ -447,7 +447,7 @@ It can help security and platform teams set the right macro controls to enforce 6. Ability to manage RBAC -A service mesh can help defenders implement a strong Role Based Access Control (RBAC) system, which is arguably one of the most critical requirements in large engineering organizations. Even a secure system can be easily circumvented by overprivileged users or employees, and an RBAC system can: +A service mesh can help defenders implement a strong Role Based Access Control (RBAC) system, which is arguably one of the most critical requirements in large engineering organizations. Even a secure system can be easily circumvented by over-privileged users or employees, and an RBAC system can: - Restrict privileged users to least privileges necessary to perform job responsibilities - Ensure that access to systems are set to “deny all” by default @@ -475,7 +475,7 @@ Since service meshes are invasive, they force developers and operators to adapt ### Implementing centralized policy management -There are numerous projects which are able to provide centralized policy management for a Kubernetes cluster, including the [Open Policy Agent](https://www.openpolicyagent.org/) (OPA) project, [Kyverno](https://kyverno.io/), or the [Validating Admission Policy](https://kubernetes.io/docs/reference/access-authn-authz/validating-admission-policy/) (a built-in, yet alpha (aka off by default) feature as of 1.26). In order to provide an example with some depth, we will focus on OPA in this cheat sheet. +There are numerous projects which are able to provide centralized policy management for a Kubernetes cluster, including the [Open Policy Agent](https://www.openpolicyagent.org/) (OPA) project, [Kyverno](https://kyverno.io/), or the [Validating Admission Policy](https://kubernetes.io/docs/reference/access-authn-authz/validating-admission-policy/) (a built-in, yet beta (aka off by default) feature as of 1.28). In order to provide an example with some depth, we will focus on OPA in this cheat sheet. OPA was started in 2016 to unify policy enforcement across different technologies and systems, and it can be used to enforce policies on a platform like Kubernetes. Currently, OPA is part of CNCF as an incubating project. It can create a unified method of enforcing security policy in the stack. While developers can can impose fine-grained control over the cluster with RBAC and Pod security policies, these technologies only apply to the cluster but not outside the cluster. @@ -613,22 +613,13 @@ First, monitor the most security-relevant container activities, including: Detecting anomalies by observing container behavior is generally easier in containers than in virtual machines because of the declarative nature of containers and Kubernetes. These attributes allow easier introspection into what you have deployed and its expected activity. -### Use Pod Security Policies to prevent risky containers/Pods from being used +### Use Pod Security Admission to prevent risky containers/Pods from being deployed -We strongly recommend that you use PodSecurityPolicy, which is a cluster-level resources available in Kubernetes (via kubectl). The PodSecurityPolicy admission controller must be enabled to use it, and given the nature of admission controllers, you must authorize at least one policy - otherwise it will not allow pods to be created in the cluster. +The previously recommended [Pod Security Policy](https://kubernetes.io/docs/concepts/policy/pod-security-policy/) is deprecated and replaced by [Pod Security Admission](https://kubernetes.io/docs/concepts/security/pod-security-admission/), a new feature that allows you to enforce security policies on pods in a Kubernetes cluster. -Pod Security Policies address several critical security use cases such as: +It is recommended to use the `baseline` level as a minimum security requirement for all pods to ensure a standard level of security across the cluster. However, clusters should strive to apply the `restricted` level which follows pod hardening best practices. -- Prevents containers from running with a privileged flag - this flag overwrites any rules you set using CAP DROP or CAP ADD and such a container will have most of the capabilities available to the underlying host. -- Prevents the host PID/IPC namespace, networking, and ports from being shared - this step ensures proper isolation between Docker containers and the underlying host -- Limits the use of volume types - writable hostPath directory volumes, for example, allow containers to write to the filesystem in a manner that allows them to traverse the host filesystem outside the pathPrefix, so readOnly: true must be used -- Puts limits on host filesystem use -- Enforces read only for root file system via the ReadOnlyRootFilesystem -- Prevents privilege escalation to root privileges -- Rejects containers with root privileges -- Restricts Linux capabilities to the bare minimum in adherence with least privilege principles - -For more information on Pod security policies, refer to the documentation at . +For more information on configuring Pod Security Admission, refer to the documentation at . ### Container Runtime Security @@ -758,12 +749,12 @@ Manifest is as follows. apiVersion: v1 kind: Pod metadata: -name: example + name: example spec: -containers: - - name: example -image: busybox -args: [/bin/sh, -c, 'while true; do echo $(date); sleep 1; done'] + containers: + - name: example + image: busybox + args: [/bin/sh, -c, 'while true; do echo $(date); sleep 1; done'] ``` To apply the manifest, run: @@ -832,7 +823,7 @@ journalctl -u ##### Cluster logging -In the Kubernetes cluster itself, there is a long list of cluster components that can be logged as well as additional data types that can be used (events, audit logs). Together, these different types of data can give you visibility into how Kubernetes is performing as a ystem. +In the Kubernetes cluster itself, there is a long list of cluster components that can be logged as well as additional data types that can be used (events, audit logs). Together, these different types of data can give you visibility into how Kubernetes is performing as a system. Some of these components run in a container, and some of them run on the operating system level (in most cases, a systemd service). The systemd services write to journald, and components running in containers write logs to the /var/log directory, unless the container engine has been configured to stream logs differently.