- TechOps Examples
- Posts
- Kubernetes Security Contexts Simplified
Kubernetes Security Contexts Simplified
Govardhana M K
October 01, 2024
TechOps Examples
Hey — It's Govardhana MK 👋
Along with a use case deep dive, we identify the top news, tools, videos, and articles in the TechOps industry.
Before we begin... a big thank you to today's sponsor.
WRITER — drag and drop to build intuitive AI apps.
Uber and Pinterest creates AI apps with this generative AI platform.
Build apps faster, find what works, and save 60% on costs too.
IN TODAY'S EDITION
🧠 Use Case Deep Dive
Kubernetes Security Contexts Simplified
🚀 Top News
Pulumi Introduces New And Updated Docker Container Images
📽️ Videos
Kubernetes Services Networking Explained
How Terraform Handles Dependencies and Uses The depends_on Argument
📚️ Articles
A List Of Cool Features of Git And GitHub
Kubectl Apply vs. Kubectl Create – What’s the Difference?
🛠️ TOOL OF THE DAY
netbox-operator - A Kubernetes operator to manage NetBox resources directly through Kubernetes.
Provides sample manifests for quick setup and testing
Supports IPv6, disaster recovery, and sticky IP address restoration.
🧠 USE CASE DEEP DIVE
Kubernetes Security Contexts Simplified
Kubernetes security contexts play a vital role in shaping the way your containers interact with their environment.
They dictate critical settings, such as user privileges, filesystem access, and process controls, ensuring that containers run with the right level of isolation and security.
Whether applied at the pod or container level, these contexts can drastically change the behavior of your applications.
To keep things simple, let's break this down into three scenarios: pod-level, container-level, and a mix of both.
Key Best Practices Settings To Know:
runAsNonRoot & runAsUser: Ensure containers don't run as root, enforcing a non-privileged user setup.
allowPrivilegeEscalation: Prevent containers from gaining additional privileges.
readOnlyRootFilesystem: Locks down the root filesystem to prevent tampering.
seccomp: Limits system calls, offering another layer of security by using profiles like
RuntimeDefaultor custom ones.
Pod-Level Example:
In this case, all containers inherit security settings from the pod's security context. Everything here is applied uniformly, meaning both the app and log containers share the same security settings. Quick, easy, and straightforward.
apiVersion: v1
kind: Pod
metadata:
name: techops-examples-pod
spec:
securityContext:
runAsUser: 3000
fsGroup: 4000
runAsNonRoot: true
allowPrivilegeEscalation: false
readOnlyRootFilesystem: true
seccompProfile:
type: RuntimeDefault
containers:
- name: app-container
image: redis:6.2
- name: log-container
image: fluentd:latest
Container-Level Example:
When you need more control, container-level security contexts allow you to tailor settings for each container.
Notice how the log-container has a different runAsUser and a custom Seccomp profile. This approach gives you fine-grained control, allowing different containers to operate under distinct security rules within the same pod.
apiVersion: v1
kind: Pod
metadata:
name: techops-examples-pod
spec:
containers:
- name: app-container
image: redis:6.2
securityContext:
runAsUser: 3000
runAsNonRoot: true
allowPrivilegeEscalation: false
readOnlyRootFilesystem: true
seccompProfile:
type: RuntimeDefault
- name: log-container
image: fluentd:latest
securityContext:
runAsUser: 5000
runAsNonRoot: true
allowPrivilegeEscalation: false
readOnlyRootFilesystem: true
seccompProfile:
type: Localhost
localhostProfile: "custom-seccomp-profile.json"
Pod + Container Level Example:
The hybrid approach lets you set defaults at the pod level, but containers can still override those defaults if needed.
Here, the app-container overrides the runAsUser field from the pod, but all other settings, like allowPrivilegeEscalation and readOnlyRootFilesystem, stick to the pod-level defaults. This provides flexibility without complicating the configuration.
apiVersion: v1
kind: Pod
metadata:
name: techops-examples-pod
spec:
securityContext:
runAsUser: 3000
runAsNonRoot: true
allowPrivilegeEscalation: false
readOnlyRootFilesystem: true
seccompProfile:
type: RuntimeDefault
containers:
- name: app-container
image: redis:6.2
securityContext:
runAsUser: 5000
runAsNonRoot: true
allowPrivilegeEscalation: false
readOnlyRootFilesystem: true
Overview of all Security Context settings and default values discussed so far.
Setting | Defaults to | Security best practice |
|---|---|---|
runAsNonRoot | FALSE | TRUE |
allowPrivilegeEscalation | TRUE | FALSE |
readOnlyRootFilesystem | FALSE | TRUE |
seccomp | undefined | RuntimeDefault or Localhost |
In short, the security context is where Kubernetes gives you the power to control the safety of your workloads, whether you need broad or fine-tuned security across pods and containers.
Hope you find this use case helpful in your learning journey!
Writer RAG tool: build production-ready RAG apps in minutes
RAG in just a few lines of code? We’ve launched a predefined RAG tool on our developer platform, making it easy to bring your data into a Knowledge Graph and interact with it with AI. With a single API call, writer LLMs will intelligently call the RAG tool to chat with your data.
Integrated into Writer’s full-stack platform, it eliminates the need for complex vendor RAG setups, making it quick to build scalable, highly accurate AI workflows just by passing a graph ID of your data as a parameter to your RAG tool.
If you're enjoying TechOps Examples please forward this email to a colleague.
It helps us keep this content free.