Container Security Best Practices Cheat Sheet
Container Security Best Practices Cheat Sheet
For example, consider a cloud-based application that uses API keys for various services.
If these keys are compromised, an attacker could gain unauthorized access. By rotating them
every 30 to 90 days, you limit the window of opportunity for an attacker to do so.
Automated systems for secret rotation, like the open-source tool Vault by HashiCorp, can
ensure that even if a secret is compromised, it won't be valid for long. For instance, the following
code will rotate secrets every 30 days:
import hvac
client = hvac.Client()
client.write('secret/my_app', api_key='1234567890')
client.renew('secret/my_app', increment=2592000)
A service mesh, such as the open-source tools Istio and Consul, can be employed to
control the traffic between containers and prevent unauthorized access. These offer
microservices architectures.
One of the critical features of a service mesh is mutual TLS (mTLS), which provides secure
communication between services. mTLS makes sure that traffic is both encrypted and
originates from a trusted source, thereby guaranteeing the integrity and confidentiality
of your data.
Consider the following diagram to understand the network flow with a service mesh:
By leveraging service meshes and mTLS, you can significantly enhance the security
Pre-runtime security measures like image scanning are essential but can't catch threats
that emerge during runtime. For example, a container might be compromised during
eBPF-based tools like Tetragon, you can detect and prevent potential dangers, such as
Tetragon is a powerful open-source tool for observing security measures and enforcing
them during runtime. It provides a wide range of use cases, including process lifecycle
monitoring, file access monitoring, network observability, and Linux process
credentials monitoring.
To illustrate how to use Tetragon for runtime security monitoring, let’s use the example
below. We'll be examining a kprobe that's attached to the fd_install kernel function.
This particular kernel function, fd_install, is invoked whenever a file descriptor is
added to a process's file descriptor table, a scenario that's commonly seen in system
calls such as open or openat:
apiVersion: cilium.io/v1alpha1
kind: TracingPolicy
metadata:
name: "fd-install"
spec:
kprobes:
- call: "fd_install"
syscall: false
args:
- index: 0
type: "int"
- index: 1
type: "file"
selectors:
- matchArgs:
- index: 1
operator: "Equal"
values:
- "/etc/passwd"
Please note that this is a simplified example, and Tetragon offers much more advanced
features and capabilities.
The diagram above provides a visual representation of how Tetragon uses eBPF to monitor
different aspects of system and network activity, providing real-time security observability
and enforcement. For more detailed examples, API references, and diagrams, please refer
to the Tetragon documentation.
The following code illustrates a tracing policy that monitors TCP connection attempts.
When a TCP connection attempt is detected, it outputs a formatted message with details
about the source, destination, user, process, and container:
apiVersion: tetragon.io/v1
kind: TracingPolicy
metadata:
name: network-observability
spec:
network:
tcpConnect:
output:
package kubernetes.admission
deny[msg] {
input.request.kind.kind == "Pod"
image := input.request.object.spec.containers[_].image
package kubernetes.admission
deny[msg] {
input.request.kind.kind == "Pod"
port := input.request.object.spec.containers[_].ports[_].hostPort
port > 0
7 Admission Controllers
An admission controller is a crucial component of advanced container security. It enforces
or blocks misconfigurations or bad behaviors before they reach the Kubernetes backend.
For example, it can prevent the deployment of containers that run as root, thereby
preventing potential security risks. Kubernetes provides a built-in admission controller that
can be configured to meet your security needs:
apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingWebhookConfiguration
webhooks:
- name: "deny-root-user.example.com"
rules:
- apiGroups: [""]
apiVersions: ["v1"]
operations: ["CREATE"]
resources: ["pods"]
scope: "Namespaced"
clientConfig:
service:
namespace: "default"
name: "deny-root-user"
8 Image Signing
Image signing, via open-source tools like Cosign or Notary, allows for the digital signing of
container images. For instance, an image might have been compromised and contain
malicious code. Ensuring that only approved and verified images can be deployed adds an
extra layer of security to your container environment.
Per advanced best practices, the leading open-source tools can be listed as follows:
By implementing these advanced practices, you can elevate your container security
approach and guarantee robust protection for your applications, no matter the threat.
In the following section, we’ll discuss container security practices based on
different environments.
Cloud provider container Ensure that images are sourced from trusted repositories.
services (EKS, ECS, Fargate, Use best practices for container construction: Minimize the
etc.) number of layers and avoid including unnecessary
components, which can introduce vulnerabilities
Regularly update the containers to ensure they have the
latest security patches and updates
Restrict container IAM privileges and implement the principle
of least privilege for container workloads
Restrict network access and use network policies to control
permissions for inter-container communication.
By tailoring your security practices to your specific environment, you will build a robust
defense capable of protecting your applications against new and emerging threats
organizations continuously face today.
The most effective security strategy is one where an organization takes proactive steps
to ensure security—not react to security incidents after the fact. By implementing these
practices, you can stay one step ahead and ensure your container environment
remains secure.