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.

When analytics on Postgres slows down, most teams add a second database. TimescaleDB by Tiger Data takes a different approach: extend Postgres with columnar storage and time-series primitives to run analytics on live data, no split architecture, no pipeline lag, no new query language to learn. Start building for free. No credit card required.

Start building for free

Powered by: Jobsurface.com

Browse 547 Worldwide Jobs Here →

Looking to promote your company, product, service, or event to 49,000+ Cloud Native Professionals? Let's work together. Advertise With Us

Kubernetes gives you enormous flexibility in how you run workloads. That flexibility is also what makes it easy to misconfigure. A cluster with default settings, no network policies, and containers running as root is not a production ready cluster, it is a set of open doors. Security in Kubernetes is not a single setting you toggle on. It is a layered set of controls that together limit what can happen if something goes wrong.

Today we cover the most important security controls in Kubernetes.

Every request to the Kubernetes API server goes through two checks before anything happens.

Authentication answers the question of who is making the request - is this a human user, a service account, or a pod?

Authorization answers what that identity is allowed to do. Kubernetes uses Role Based Access Control as its authorization mechanism, and understanding how RBAC works is the foundation of everything else.

RBAC has two core object types that work together. Roles define what actions can be performed on which resources. A Role might say: get, list, and watch pods in a specific namespace. A ClusterRole says the same but applies cluster wide rather than being scoped to a single namespace.

RoleBindings and ClusterRoleBindings then assign those roles to specific identities, a user, a group, or a service account. The separation is important: the Role describes capabilities, the Binding describes who has them.

The most common RBAC mistake is over permissioning. A service account that only needs to read ConfigMaps in one namespace should not have cluster admin. A developer who needs to view pod logs should not have the ability to delete namespaces. The principle of least privilege applies here exactly as it does everywhere else in security. Every role you create should grant only the permissions the identity actually needs and nothing more. Audit your RBAC rules regularly, permission creep in Kubernetes is real and it accumulates silently.

By default, every pod in a Kubernetes cluster can reach every other pod, regardless of namespace. There are no network level restrictions. In a small cluster with trusted workloads this is manageable. In a multi tenant cluster or any environment handling sensitive data, it is a significant risk. If one pod is compromised, it can freely connect to any other pod in the cluster.

Network Policies are Kubernetes objects that define rules for which pods can communicate with which other pods and on which ports. They work at the IP and port level inside the cluster and are enforced by the network plugin, not Kubernetes itself. This means you need a CNI plugin that supports NetworkPolicy enforcement, Canal, Calico, Cilium, and Weave all do. Flannel alone does not.

The recommended approach is to start with a default deny policy in every namespace. An empty podSelector with policyType: Ingress blocks all inbound traffic to all pods in the namespace. You then add specific allow policies for the traffic that actually needs to flow. A policy allowing the web pod to reach the db pod on port 3748 is explicit, auditable, and scoped precisely to what is needed. Everything else stays blocked. This deny-by-default posture means that a new pod added to the namespace has no network access until someone explicitly creates a policy for it, which is the correct default behaviour in a production environment.

🔴 Get my DevOps & Kubernetes ebooks! (free for Premium Club and Personal Tier newsletter subscribers)