My neighbour in Chennai has a ritual that starts every October. She walks the terrace with a torch, pokes at the drain outlets, checks the seal around the water tank and tests the sump pump while it is still dry. Her argument is simple: nobody inspects a drain in the middle of a downpour, so you do it when the sky is merely threatening. When I first started reading about how teams protect the container clusters behind their websites, I kept hearing her voice. The routine has a name in the Ops Atlas, KubernetesSecOps, but what it comes down to is a pre-monsoon walk-round for software.<\/p>\n
This article turns that walk-round into a checklist you can follow in an afternoon. You can be a founder, an operations person or a curious reader; each step is stated so it can be handed to whoever runs your hosting, along with a question to ask and a clear sign that it is done.<\/p>\n
Take the list from the Atlas page on KubernetesSecOps<\/a> as a map, not a verdict. That page treats the discipline as the daily upkeep of who may alter a cluster, what is allowed to run, what may connect, how secrets are held and how attacks surface. Anything about upgrading the cluster itself or building the software images sits elsewhere, so this walk-round does not cover them.<\/p>\n One more ground rule, borrowed from my neighbour: do not fix anything on the first pass. Walk, note, then decide. In the Atlas’s own staged approach the early weeks are about looking, and nothing should be switched to blocking until people have had notice.<\/p>\n Ask:<\/strong> Where is the record of who did what in our cluster?<\/p>\n Why it matters:<\/strong> If you run the control plane yourself, there is no activity log at all until an audit policy is supplied. For hosted services the Atlas says defaults differ: per its October 2026 notes, one large provider stays silent about the control plane until logging is switched on, while another always retains administrator activity yet leaves data-access records disabled.<\/p>\n Done when:<\/strong> you can find yesterday’s changes with a person’s name beside each. Watch the order of the policy rules, since the first rule that matches decides, and keep secrets recorded as metadata only.<\/p>\n Ask:<\/strong> Are stored secrets encrypted at rest, and with which method?<\/p>\n Why it matters:<\/strong> By default they sit unencrypted in the datastore. Base64, the odd-looking encoding you see on them, is not a lock. The Atlas recommends the current key-management integration and rates one local cipher option as weak.<\/p>\n Done when:<\/strong> the answer names a key service, and someone can say who holds the key.<\/p>\n Ask:<\/strong> Which workloads would be blocked by the built-in baseline standard if we enabled it today?<\/p>\n Why it matters:<\/strong> The standard has three levels, and its strictest asks that programs avoid running as an administrator, forbid privilege escalation, use the runtime’s default syscall filtering and drop all extra capabilities. The Atlas says to start by warning, not blocking, and that the check applies to new pods only.<\/p>\n Done when:<\/strong> you hold a list of would-be rejections for every namespace, with owners named.<\/p>\n Ask:<\/strong> Can any pod talk to any other pod?<\/p>\n Why it matters:<\/strong> Without a network policy, yes. The Atlas advises a default-deny rule in each application namespace with only the needed paths opened afterwards. Connections open before the change might continue, as the Atlas leaves that behaviour to the network plugin, so schedule a restart.<\/p>\n Done when:<\/strong> a pilot namespace is closed and the application still works.<\/p>\n Ask:<\/strong> Who holds powerful rights, and does any automated tool hold a master role?<\/p>\n Why it matters:<\/strong> Handing the top-level role to the delivery pipeline is one of the Atlas’s named anti-patterns. So is adding people to the built-in group that skips all permission checks.<\/p>\n Done when:<\/strong> every powerful right has a name and a reason, and the shortcuts are gone.<\/p>\n Ask:<\/strong> Where do we write down rules we are knowingly bending?<\/p>\n Why it matters:<\/strong> Every household has a leak it has decided to live with until the roof is redone. The danger is forgetting. The Atlas wants an exception register where each entry expires, plus a monthly look.<\/p>\n Done when:<\/strong> the register exists and every entry carries an end date.<\/p>\n Ask:<\/strong> If one pod looked compromised tonight, what would we actually do?<\/p>\n Why it matters:<\/strong> A neighbour once told me that the worst part of the 2015 floods was not the water but the confusion about who should do what. The Atlas’s guidance is specific: do not delete the pod automatically, because that destroys evidence and does not cancel any stolen tokens. Relabel it so traffic stops reaching it, then investigate.<\/p>\n Done when:<\/strong> the team has practised the relabel step once and written down what went wrong.<\/p>\n Ask:<\/strong> Could someone with a laptop and the right rights deploy something that never passed our build checks?<\/p>\n Why it matters:<\/strong> Command-line tools and package managers can talk to the cluster directly, skipping the pipeline altogether. That is why the Atlas places verification at the cluster’s own doorway, by checking image digests and, in a later stage, signatures. It also cautions against the opposite excess of blocking every image that a scanner flags, which leads to constant breakage.<\/p>\n Done when:<\/strong> at least one rule judges images at admission, and it has been through the warn-first routine.<\/p>\n When the walk-round is finished you will have one of three outcomes. Some items are already fine. Some need a quick fix. A few need a conversation. Resist the urge to treat the list as a score, and resist the urge to be embarrassed by it; every household finds something on the terrace. The Atlas gives a worked example with figures, 40 of 46 namespaces at the baseline level or above and 22 at the strictest, and says plainly that such coverage numbers describe breadth, not quality.<\/p>\n If you are new to the city and thinking about timing for a visit, the guide to planning a first Chennai trip<\/a> and this one on how long to stay<\/a> will help you pick a calmer month than the monsoon peak, which seems a fitting thing to know alongside a pre-monsoon routine.<\/p>\n Walk-rounds only help if they recur. The Atlas suggests a weekly glance at rejections and alerts, a monthly pass over exceptions, a quarterly review of access rights, and an annual rehearsal with the security operations team. Choose the dates now and put them where your team will see them.<\/p>\nStep 1: Check that something is writing things down<\/h2>\n
Step 2: Open the drawer where passwords live<\/h2>\n
Step 3: Walk the terrace for loose tiles<\/h2>\n
Step 4: Close the drain outlets one by one<\/h2>\n
Step 5: Count the keys<\/h2>\n
Step 6: Keep a receipt book for exceptions<\/h2>\n
Step 7: Rehearse the flood<\/h2>\n
Step 8: Check who delivers the parcels<\/h2>\n
Reading your results<\/h2>\n
Keeping the habit alive<\/h2>\n