{"id":946,"date":"2026-11-14T17:00:00","date_gmt":"2026-11-14T17:00:00","guid":{"rendered":"https:\/\/heartcareforyou.in\/blog\/?p=946"},"modified":"2026-11-15T07:00:00","modified_gmt":"2026-11-15T07:00:00","slug":"kubesecops-ninety-day-audit-checklist","status":"publish","type":"post","link":"https:\/\/heartcareforyou.in\/blog\/kubesecops-ninety-day-audit-checklist\/","title":{"rendered":"A 90-Day KubernetesSecOps Audit Checklist for Digital Health Teams"},"content":{"rendered":"

Digital health products run on infrastructure that someone has to keep orderly, and for many teams that infrastructure is a Kubernetes cluster. This checklist turns KubernetesSecOps into a ninety-day audit you can hand to an engineering lead, a platform owner or an external reviewer. It is non-clinical: nothing here touches patient care, only the way the computing platform behind an application is configured and watched. Each step is phrased as a check with an expected result, so the outcome can be recorded as pass, partial or fail.<\/p>\n

The ninety-day structure follows the staged plan described in the Ops Atlas, which splits the work into a “see” phase, a “guard” phase and a “verify” phase. I have rewritten the steps as a checklist and added the evidence to collect at each stage. The original discussion is at the Ops Atlas page for KubernetesSecOps<\/a>, and it is worth skimming before you assign owners.<\/p>\n

Before you start: scope and owners<\/h2>\n

Write down which clusters are in scope, who owns each, and who can approve a change to security rules. A checklist without named owners becomes a wish list. Also decide the unit of reporting; the Atlas’s worked example counts workload namespaces, which is a sensible unit because rules are applied per namespace. Record the total number so that every later percentage has a denominator.<\/p>\n

Days 1 to 30: see what exists<\/h2>\n

The aim of the first phase is visibility. Do not change enforcement yet.<\/p>\n

    \n
  1. Inventory namespaces and owners.<\/strong> Expected result: every namespace has a named owner and a purpose. Evidence: a table exported from the cluster and reconciled by hand.<\/li>\n
  2. Turn on authentication through the organisation’s identity provider.<\/strong> Expected result: people sign in with individual accounts, not a shared certificate. Evidence: the cluster configuration and a test login.<\/li>\n
  3. Enable audit logging.<\/strong> Expected result: an audit policy exists, logs are shipped somewhere they cannot be edited by cluster administrators, and retention is written down. On a self-managed cluster nothing is logged until a policy file is supplied, and managed services differ in what they record by default, so verify the actual behaviour rather than assuming it.<\/li>\n
  4. Switch Pod Security to warn mode at the baseline level everywhere.<\/strong> Expected result: violations are visible but nothing is blocked. Evidence: the list of warnings by namespace.<\/li>\n
  5. Run a benchmark scan.<\/strong> Expected result: a report against the current CIS Kubernetes Benchmark with each failing item assigned an owner. Tools such as kube-bench perform this scan.<\/li>\n<\/ol>\n

    Days 31 to 60: put guardrails in place<\/h2>\n

    The second phase begins enforcement, but carefully.<\/p>\n

      \n
    1. Announce an enforcement date for the baseline profile.<\/strong> Expected result: owners have had roughly two weeks of warnings, the date is published, and an exception register with expiry dates exists.<\/li>\n
    2. Enforce baseline.<\/strong> Expected result: at least nine in ten workload namespaces comply, the remainder covered by dated exceptions. Remember that enforcement does not remove pods that are already running, so review those separately.<\/li>\n
    3. Pilot default-deny network rules.<\/strong> Expected result: one or two namespaces run with explicit allow lists. Note that connections opened before the rule was applied may continue, depending on the network plugin, so restart workloads during the test.<\/li>\n
    4. Turn on encryption of secrets at rest.<\/strong> Expected result: secrets are encrypted using an external key service via the current provider interface. Per the Atlas, the first generation of that interface has been on its way out since v1.28 and is off by default in the next release, while the plain symmetric cipher option earns a “weak” rating. Confirm any data stored before encryption was enabled has been rewritten.<\/li>\n
    5. Connect alerts to the team that responds.<\/strong> Expected result: runtime detection output reaches an on-call queue with a named recipient.<\/li>\n<\/ol>\n

      Days 61 to 90: verify and rehearse<\/h2>\n
        \n
      1. Apply the restricted profile to new namespaces.<\/strong> Expected result: new spaces start with non-root users, no privilege escalation, the runtime-default syscall filter and all extra capabilities dropped.<\/li>\n
      2. Add a rule that pins images by digest.<\/strong> Expected result: workloads that refer to mutable tags are rejected in the pilot scope.<\/li>\n
      3. Pilot signature checking at admission.<\/strong> Expected result: unsigned images are refused in one namespace. The Atlas argues for checking here as well as in the pipeline, because command-line tools and package managers can reach the cluster without passing through the pipeline.<\/li>\n
      4. Run a tabletop drill with the security operations team.<\/strong> Expected result: a written record of what the team did with a simulated alert, and what they would change.<\/li>\n
      5. Review the numbers.<\/strong> Expected result: percentages for baseline, restricted and default-deny coverage, plus an actionable-alert rate.<\/li>\n<\/ol>\n

        How to score the audit<\/h2>\n

        Give each of the fifteen checks a score: two for pass with evidence, one for partial, zero for fail. Thirty is the maximum. Do not average away the zeros; list them first in the report. A score is a conversation starter and not a grade, because a team that scores twenty-two and has a dated plan for the rest is in better shape than a team that scores twenty-six and cannot say who owns the failures.<\/p>\n

        For the metric lines, borrow the style of the Atlas’s example, which reported coverage as simple fractions of namespaces: baseline-or-better, restricted and default-deny. Fractions are easy to recompute and hard to inflate. The same example reported that a high-volume alert feed contained only a small share of items needing action until expected on-call activity was excluded, which is a reminder to report an actionable rate next to raw volume.<\/p>\n

        The evidence pack to keep<\/h2>\n

        Audits fail quietly when proof lives in people’s heads. Keep a folder, with one subfolder per phase, holding the artefacts that justify each score: exported role lists, screenshots of the identity provider settings, the audit policy file, the benchmark report, the warning counts before and after enforcement, the exception register and the notes from the drill. Date every file. A reviewer who arrives six months later should be able to reconstruct why a check passed without interviewing anyone.<\/p>\n

        Keep the pack small enough to read. Ten well-labelled files beat two hundred raw exports, and a one-page index that lists each check beside its evidence file saves the most time of all.<\/p>\n

        A reporting template for the sponsor<\/h2>\n

        Executives do not read fifteen checks. Give the sponsor four lines: the score and its change since the last round, the three lowest-scoring checks with owners and dates, the count of open exceptions past their expiry, and one decision needed from them. That last line is what turns an audit into progress, because most stuck items wait on a decision about priority or budget, not on engineering effort.<\/p>\n

        Items auditors often forget<\/h2>\n