SEBI CSCRF and Kubernetes: what policy can enforce

SEBI’s Cybersecurity and Cyber Resilience Framework (CSCRF) does not name Kubernetes. Several of its Protect and Identify standards, though, describe configuration that a cluster policy can check: hardened workloads, least privilege, a baseline and an asset inventory. Logging, MFA, monitoring and change approval need other evidence.

What the CSCRF asks for

The circular dated August 20, 2024 (SEBI/HO/ITD-1/ITD_CSC_EXT/P/CIR/2024/113) sets out standards grouped by cybersecurity function (Govern, Identify, Protect, Detect, Respond and Recover). It applies to all SEBI Regulated Entities, with the depth of each control depending on one of five categories, from MIIs down to self-certification entities.

The standards that touch a container platform sit mostly under Identify (asset inventory), Protect (identity, access, baseline configuration and hardening) and Detect (continuous monitoring). The circular does not say how to meet them on Kubernetes, so the mapping below is ours. It is not SEBI guidance.

The circular was clarified on August 28, 2025 (SEBI/HO/ITD-1/ITD_CSC_EXT/P/CIR/2025/119). Read the clarifications with the base text, because some clauses changed meaning.

Which controls policy can enforce

CSCRF standard	What it asks for	Kubernetes control	Enforced by policy?
PR.IP baseline, standard 1	Baseline configuration built on least functionality	Pod Security Standards (restricted profile) through namespace labels	Yes, at admission
PR.IP.S1 hardening	Default credentials replaced, unneeded services removed, non-default ports, open ports blocked	Pod spec fields such as hostNetwork, hostPort and privileged	Partly
PR.AA.S3 least privilege	Least privilege on resources, with segregation of duties	Container securityContext (runAsNonRoot, capabilities)	Partly. RBAC review is separate
PR.AA.S4, clarified in 2025	Zero trust, with segmentation and no single point of failure	NetworkPolicy objects	Partly. A policy can protect the NetworkPolicies themselves
ID.AM.S1, S4	Asset inventory updated within 3 working days	API inventory, policy reports	Evidence only
PR.IP.S3 change management	Controlled, approved changes	Git review, admission checks	Process controls, mostly outside the cluster
PR.AA.S8, S9 logging	Log management policy, user logs kept for a set period	kube-apiserver audit policy	No. Set on the control plane
PR.AA.S7 MFA	MFA for critical systems reached from untrusted networks	Identity provider	No
DE.CM.S1 monitoring	SOC running 24x7x365	Monitoring stack and SOC	No

The mapping is ours, not SEBI’s. Each “Partly” row needs a named owner.

The clauses policy cannot reach

Three CSCRF areas sit outside an admission policy, and an assessor will ask about each one.

Log management is configured on the API server. Kubernetes writes audit events only when kube-apiserver is started with an audit policy file, and the policy picks a level per request, from Metadata up to RequestResponse. A Kyverno policy report records admission results. It is not an audit log.

Access reviews and MFA belong to the identity provider and to the people who run the reviews. A policy can stop a pod from running as root. It cannot show that a privileged user’s activity was reviewed.

Monitoring under DE.CM.S1 is a 24x7 operating function. Document where the SOC gets Kubernetes audit events and who acts on them.

Gotchas from the circular and the Kubernetes docs

Several rules are easy to get wrong when you read the text quickly.

Pod Security Admission modes differ. The enforce mode rejects a pod that violates the level. The audit mode only adds an annotation to the audit log, and warn only shows a warning. A namespace labelled only with warn still admits the pod. The warning goes to whoever applied it, not to a log an assessor will read.

NetworkPolicy is allow-all by default. The Kubernetes docs state that a pod is non-isolated for ingress and egress until a policy selects it. Zero trust in the 2025 clarification therefore needs a default-deny policy per namespace, which you must write.

Secrets are stored in plain text by default. The API server stores resources in etcd without encryption unless --encryption-provider-config is set and the first provider in that file is not identity. A policy cannot add that setting.

The 2025 clarification widens scope. Any system on the same network segment as a critical system is now treated as critical. Map the segments before you decide what a cluster covers.

Data localisation is in abeyance. The 2025 clarification table records that data classification and localisation were put in abeyance by a December 31, 2024 circular. Check that status before you design around it.

A checklist before you scope the work

1. List each CSCRF category that applies to your entity, and the standards its applicability column marks as mandatory.
2. Map each standard to a control type: admission policy, cluster configuration, identity provider, or operating process.
3. Put the critical systems and their network segments on paper, including any cluster on the same segment.
4. Start with Pod Security Admission in warn or audit mode and read the results before you enforce.
5. Add a default-deny NetworkPolicy to each namespace that holds a critical workload.
6. Turn on API server audit logging with a written policy, and name who reviews it.
7. Keep the mapping in version control with the date of the circular it cites.

Enforcing this with Kyverno

Kyverno is open source and can enforce the admission rows of the table. The validate rule below is trimmed from the Kyverno docs’ own example, which also covers initContainers. It rejects a pod unless runAsNonRoot is true at pod level or on each container that sets a securityContext, and failureAction: Enforce blocks the pod. Set failureAction: Audit to report without blocking.

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: require-run-as-non-root
spec:
  background: true
  rules:
    - name: check-containers
      match:
        any:
          - resources:
              kinds:
                - Pod
      validate:
        failureAction: Enforce
        message: "Running as root is not allowed."
        anyPattern:
          - spec:
              securityContext:
                runAsNonRoot: true
              containers:
                - =(securityContext):
                    =(runAsNonRoot): true
          - spec:
              containers:
                - securityContext:
                    runAsNonRoot: true

Kyverno’s docs mark validationFailureAction as deprecated, so use the rule-level failureAction shown here. We ran this policy with the Kyverno CLI 1.15.2 (kyverno apply) against five test pods. A pod with runAsNonRoot: true at pod level passed, and so did a pod that set it on every container. A pod with no setting, a pod whose container overrode the pod-level setting with false, and a pod with one container missing the setting were all rejected. The CLI runs the same validation as the admission controller, but we did not test it against a live cluster. The Kyverno docs recommend the Helm chart for production installs, so pin the chart version and repeat these cases on your cluster.

For the sequence, read the policy reports first, then move to Enforce. The same reports are the configuration evidence for the admission rows. They do not replace the audit log or the access reviews in the table above. See the continuous compliance hub for the wider approach, and the Kyverno project page for the tool. For the same control-by-control approach on other frameworks, read the PCI DSS post, the NIST 800-53 mapping and the evidence guide.

Sources checked on 2026-11-12: the SEBI CSCRF circular of 20 August 2024, the 2025 clarification circular, the Kubernetes Pod Security Standards, the Kubernetes NetworkPolicy docs, and the Kyverno validate rule docs.

Frequently asked questions

Does SEBI's CSCRF mention Kubernetes or containers?

No. The circular dated August 20, 2024 does not name Kubernetes. It is written as technology-neutral standards for the Protect, Identify and Detect functions, and it applies to cloud assets through the standards that cover shared resources and cloud deployments. You map the standards to your platform yourself, and an auditor will expect that mapping to be written down.

Can a Kubernetes admission policy satisfy a CSCRF clause on its own?

Only for clauses that describe a resource configuration, such as privileged containers, runAsNonRoot or an open host port. Clauses on logs, access reviews, MFA, change approval and SOC monitoring need evidence from the cluster, the identity provider or the operating process. A policy report can show a configuration check passed. It cannot show that someone reviewed the access.

Does the CSCRF apply to every firm that uses Kubernetes?

It applies to SEBI Regulated Entities, which the circular groups into five categories: MIIs, Qualified REs, Mid-size REs, Small-size REs and Self-certification REs. Several controls differ by category, so check the applicability column for your category before you plan the work.

Does the 2025 clarification change the Kubernetes scope?

It does, in one way that matters for clusters. The August 28, 2025 clarification says critical systems include any system on the same network segment as a critical system. A cluster that shares a segment with a payment or trading system can fall into scope even if the cluster itself holds no critical data.