TechOps Examples
Hey — It's Govardhana MK 👋
Welcome to another technical edition.
Every Tuesday – You’ll receive a free edition with a byte-size use case, remote job opportunities, top news, tools, and articles.
Every Thursday and Saturday – You’ll receive a special edition with a deep dive use case, remote job opportunities and articles.
Top engineers at Anthropic and OpenAI say AI now writes 100% of their code.
If you're not using AI, you're spending 40 hours doing what they do in 4.
These 100+ Claude Code hacks fix that and help you ship 10x faster.
Sign up for The Code and get:
100+ Claude Code hacks used by top engineers — free
The Code newsletter — learn the latest AI tools, tips, and skills to code faster with AI in 5 minutes a day
If you’re not a subscriber, here’s what you missed last week.
To receive all the full articles and support TechOps Examples, consider subscribing:
🛠 TOOL OF THE DAY
Dockhand - The Ultimate Self Hosted Docker Management Tool.
A modern, efficient Docker management application providing real-time container management, Compose stack orchestration, and multi-environment support.
All in a lightweight, secure and privacy focused package.
🧠 USE CASE
How to protect Kubernetes using Namespaces
Before we talk about protecting Kubernetes using namespaces, we need to clear up a confusion that trips up even experienced DevOps engineers.
Namespaces vs cgroups
Namespaces and cgroups solve two very different problems.
Namespaces answer the question: what can I see?
They isolate views of the system. Processes, network interfaces, mounts, users, hostnames. A container sees only what its namespace exposes. It cannot see other containers, host processes, or unrelated resources.
cgroups answer the question: how much can I use?
They limit and account for CPU, memory, disk IO, and pids. A container can see its world just fine but cgroups decide how much of the host it is allowed to consume.
Kubernetes builds on both, but when we talk about protecting Kubernetes, we are mostly talking about controlling visibility and access. That is a namespace problem, not a cgroup problem.
How namespaces protect a Kubernetes cluster
Namespaces create logical boundaries inside a shared cluster. They do not isolate nodes or the kernel. They isolate access and visibility.
They scope: Pods, Services, ConfigMaps, Secrets, RBAC permissions, Network policies, Default service accounts, Resource quotas
Step 1: Define Roles (Role or ClusterRole): What actions are allowed within a namespace (Role) or across the entire cluster (ClusterRole).
Step 2: Creating Service Accounts or Users/Groups: Set up service accounts within Kubernetes or manage external users/groups to take on these roles.
Step 3: Bind Roles to Accounts, Users, or Groups: Use RoleBindings to connect roles to service accounts or users within a namespace, or ClusterRoleBindings for cluster wide permissions.
To further understand how this operates, let’s break down the key roles in Kubernetes:
Cluster-admin: Acts as a superuser with full control over all resources across the cluster and namespaces.
Admin: Grants complete read and write access within a specific namespace, including creating roles and bindings but not modifying the namespace itself.
Edit: Allows read and write permissions within a namespace, excluding the ability to view or modify roles or bindings.
View: Provides read-only access within a namespace, without permission to view or change roles or bindings.
The core idea to remember
cgroups protect the node from containers.
Namespaces protect workloads and teams from each other.
🔴 Get my DevOps & Kubernetes ebooks! (free for Premium Club and Personal Tier newsletter subscribers)
Looking to promote your company, product, service, or event to 50,000+ DevOps and Cloud Professionals? Let's work together.
