Day 23 — Secure By Design (Black Forest Shadow)

Gord and Rothütle take Jack to the castle. As they enter the courtyard, YAML emerges from the shadows, holding a small box.

"Looking for this?" he says, handing the box to Gord.

Then the sky grows dark, and a cold wind sweeps through the forest.

A large dark figure starts to materialize in front of them.

"It's Angra," Gord whispers.

"The Architect is free now," Jack says, stepping back.

Then Jack and YAML go and stand beside the dark figure.

"YAML was on my side all along," Angra's voice echoes through the stone walls.

"So your tall friend is not so useless after all," Rothütle mutters.

"Don't bet on it," Gord replies.

"You can't stop me now," Angra continues.

"So Jack was just a distraction," Rothütle says, realizing the truth.

"We were playing into Angra's hands all along."

"So, you have a miner, a useless moving tower, and some shadows that vanish in torchlight," Gord shouts, facing Angra.

"That makes you unstoppable?"

Angra snarls. Jack picks up an axe and YAML draws his dagger.

---

Tip of the day: Misconfiguration is an attacker's best friend. Secure your systems by design.

---

Security Tip #23 — Secure by Design

Angra wins not by strength, but by exploiting weaknesses in the defenders' design.

YAML, who was supposed to be the guard, opened the door for the enemy.

It's the same with your YAML configurations and infrastructure as code. If misconfigured, they can open the door to attackers.

Here are some best practices to ensure your systems are secure by design:

• Use secure defaults: Start with the most restrictive settings and only open up what is necessary.
• Implement the principle of the least privilege: Ensure that users and services have only the permissions they need to perform their tasks.
• Pod Security Standards: There are three predefined Pod Security Standards in Kubernetes: Privileged, Baseline, and Restricted. Use the Restricted profile for production workloads to minimize security risks and only allow necessary capabilities.
• Drop unnecessary capabilities: Docker containers run with a default set of Linux capabilities. You can drop all capabilities and only add back the ones you need using the cap_drop and cap_add options in your Docker Compose or Kubernetes manifests.

Pod Security Standards Example

apiVersion: v1
kind: Namespace
metadata:
  name: default
  labels:
    pod-security.kubernetes.io/enforce: baseline
    pod-security.kubernetes.io/audit: restricted

Here, the default namespace is configured to enforce the Baseline Pod Security Standard and audit against the Restricted standard.
This means that any pods created in this namespace must comply with the Baseline standard, and any violations of the Restricted standard will be logged for auditing purposes.

Dropping Unnecessary Capabilities Example

apiVersion: v1
kind: Pod
metadata:
  name: nginx
spec:
  containers:
  - name: nginx
    image: nginx
    securityContext:
      capabilities:
        drop: ["ALL"]
        add: ["NET_ADMIN"]

In this example, the Nginx container drops all Linux capabilities and only adds back the NET_ADMIN capability, which is necessary for network administration tasks.

Learn Docker and Kubernetes Security

These two examples were taken from my book Docker and Kubernetes Security, currently 40% off.

Chapter 6 covers securing containers in Kubernetes, including Pod Security Standards and capability management.

🔗 buy.DockerSecurity.io

💬 Code: BLACKFOREST25

👉 To have the story delivered to your inbox every day in December, subscribe to my Medium publications.