Platform Security

What it is

Platform security is the practice of embedding security controls into the platform itself — the CI/CD pipelines, Kubernetes admission layer, secrets management infrastructure, and RBAC configuration — so that all applications built on the platform are secure by default without requiring each team to independently implement and maintain security controls. Rather than telling 20 teams "you must implement image signing, container security scanning, secrets rotation, and least-privilege RBAC for your Kubernetes workloads," the platform team implements these controls centrally and enforces them through the platform layer. Teams benefit from the security baseline automatically; they cannot accidentally (or deliberately) deploy insecure workloads because the platform prevents it.

The key technologies for platform security in the Kubernetes ecosystem are: OPA/Gatekeeper (Open Policy Agent with the Gatekeeper Kubernetes admission webhook) for policy-as-code enforcement at the Kubernetes API layer; Cosign/Sigstore for container image signing and verification (ensuring only images built by the organisation's CI pipeline can be deployed); the External Secrets Operator (ESO) for platform-wide secrets injection (syncing secrets from AWS Secrets Manager, HashiCorp Vault, or GCP Secret Manager into Kubernetes Secrets automatically); and templated RBAC configurations that are provisioned per team namespace rather than being configured manually by individual teams.

Why it exists

In organisations with many application teams, security inconsistency is inevitable when teams are responsible for their own security implementation. Audit findings consistently show that some teams configure container security contexts correctly (non-root, read-only filesystem, dropped capabilities) while others run containers as root with host network access. Some teams use secrets injection via ESO; others commit base64-encoded secrets to Kubernetes manifests (which end up in git history). Some teams implement proper RBAC; others bind all service accounts to cluster-admin "temporarily" during debugging and never revert. The platform security model addresses this by enforcing minimum security standards through the Kubernetes admission layer — a pod that violates the security policy is rejected at apply time, before it ever reaches the container runtime.

Platform security also reduces the cognitive load of security compliance on application teams. A team that must read the AWS security whitepaper, understand Kubernetes security contexts, implement IRSA (IAM Roles for Service Accounts), configure network policies, set up image scanning, and generate SBOMs to pass an audit is spending a significant fraction of its time on undifferentiated security work. The platform team that implements these controls centrally and exposes them through golden paths allows application teams to be secure without being security experts — security is a platform service rather than a per-team responsibility.

When to use

• Implement OPA/Gatekeeper admission policies for all Kubernetes clusters as soon as Kubernetes is in use — the cost of retrofitting policies to an already-running cluster is much higher than enforcing from the start.
• Use image signing (Cosign) and policy controller verification when supply chain security is a concern — this is a best practice for any production workload and a requirement for SOC2 Type II, PCI-DSS, and NIST SSDF compliance.
• Deploy External Secrets Operator org-wide as the standard secrets injection mechanism whenever teams are using more than one cloud-native secrets store (AWS Secrets Manager, HashiCorp Vault) or when Kubernetes Secrets with base64-encoded values are present in git.
• Provision RBAC templates per team namespace automatically as part of the namespace provisioning workflow — RBAC configuration should never be a manual step for individual teams.
• Use compliance-as-code guardrails (Gatekeeper policies, SBOM generation, image scanning) whenever there is a regulatory or audit requirement that applies uniformly to all services.

When not to use

• Over-aggressive admission policies before testing: Deploying strict Gatekeeper policies (deny all privileged containers, deny all host mounts) to a running production cluster without thorough testing will break workloads; deploy in audit mode first, fix violations, then switch to enforce mode.
• ESO without secret lifecycle management: ESO syncs secrets into Kubernetes but does not handle secret rotation scheduling; if the upstream secret (in Vault or Secrets Manager) is rotated, ESO will sync the new value, but the workload must gracefully handle secret reload without restart — verify this before adopting ESO.
• Cosign in keyless mode in air-gapped environments: Keyless Cosign signing uses Sigstore's Fulcio CA and Rekor transparency log, which requires internet access; in air-gapped environments, use a self-hosted Sigstore stack or a private key-based signing workflow.

Typical architecture

Platform Security Architecture (Kubernetes)
──────────────────────────────────────────────────────────
  Build time (CI pipeline — enforced via shared workflow)
  ├── SAST scan            (Semgrep / CodeQL)
  ├── SCA scan             (pip-audit / npm audit / trivy)
  ├── Container image scan (Trivy — fails on Critical CVEs)
  ├── SBOM generation      (Syft → CycloneDX JSON)
  └── Image signing        (Cosign keyless via OIDC token)
       └── Signature stored in: OCI registry (ECR/GCR)

  Admission time (Kubernetes API server)
  ├── OPA Gatekeeper ConstraintTemplates
  │   ├── deny: containers running as root (UID 0)
  │   ├── deny: privileged pods
  │   ├── deny: host network / host PID
  │   ├── require: resource limits (CPU + memory)
  │   ├── require: labels (team, service, tier)
  │   └── deny: unsigned images (Cosign policy controller)
  └── Policies stored as CRDs, versioned in git (GitOps)

  Runtime (secrets + access)
  ├── External Secrets Operator
  │   ├── Reads from: AWS Secrets Manager / Vault
  │   ├── Creates: Kubernetes Secrets per namespace
  │   └── Auto-refresh: every 15 minutes
  ├── IRSA / Workload Identity
  │   └── Pod → IAM role binding per service account
  └── Network Policy (per-namespace, via Helm chart)
      └── Default deny-all ingress/egress
          + explicit allow rules per service dependency

  Per-team RBAC (provisioned on namespace creation)
  ├── developer Role: get/list/watch pods/logs
  ├── deployer Role: apply deployments (CI service account)
  └── admin RoleBinding: team leads only (never cluster-admin)

Pros and cons

Implementation notes

For OPA Gatekeeper: deploy in audit mode first and run it for 2–4 weeks against the production cluster before switching to enforcement mode. Gatekeeper's audit controller will report all existing violations without blocking deployments, giving the platform team a complete picture of the security debt to address. Prioritise constraint enforcement based on severity: the pod security standards (no privileged containers, no root, required resource limits) should be enforced first; label requirements and image signing can follow once the critical controls are in. Store all ConstraintTemplate and Constraint resources in a dedicated git repository managed by the platform team, deployed via ArgoCD — this ensures policy changes follow the same review and rollout process as application changes.

For External Secrets Operator: deploy with a ClusterSecretStore pointing to the organisation's primary secrets store (AWS Secrets Manager or HashiCorp Vault), and create per-namespace ExternalSecret resources automatically as part of the namespace provisioning workflow. Define a naming convention for secret paths that includes the team name and environment (/platform/team-checkout/prod/db-password) and document it in the developer portal. Configure ESO to refresh secrets every 15 minutes and label injected Kubernetes Secrets with managed-by: external-secrets to prevent manual modification. Test secret rotation end-to-end before onboarding teams — the workload must handle secret reload without a full pod restart (using a secrets-reloader sidecar, or application-level reload logic via inotify).

Common failure modes

• Policy deploy to production without audit mode: Platform team ships a Gatekeeper policy that denies containers without resource limits; 15 services in production have no resource limits; all 15 block on the next deployment; emergency incident; rollback required; always run in audit mode for minimum 2 weeks before enforcing.
• Image signing blocking hotfix deployments: Production incident requires hotfix deployment; hotfix image is built in 5 minutes but Cosign signing step fails because Sigstore Fulcio is experiencing an outage; deployment is blocked; maintain a signed "break-glass" deployment path that bypasses the policy controller under explicit on-call authorisation.
• ESO RBAC too permissive: ESO ClusterSecretStore uses an IAM role with secretsmanager:GetSecretValue for all secrets in all environments; a bug in ESO or a compromised ESO pod can read all secrets; scope ESO IAM roles per environment (prod ESO reads only prod secrets) and per namespace where possible.
• RBAC template applied with cluster-admin binding: Namespace provisioning template incorrectly binds the team's CI service account to ClusterRole cluster-admin "for simplicity"; all CI pipelines can modify all namespaces; compromised CI token is a full cluster takeover; audit all ClusterRoleBindings quarterly; use namespace-scoped Roles, never cluster-admin for application workloads.
• Network policy gaps at service launch: Default-deny network policy is enforced; new service launches without its outbound network policy defined; service cannot reach its database; deployment fails silently (service starts but returns 500s); include network policy validation in the service golden path template so that all required policies are created at service provisioning time.

Decision checklist

• Are OPA/Gatekeeper policies running in audit mode for at least 2 weeks before switching to enforcement, with all violations resolved?
• Are image signing (Cosign) and policy controller verification in place for all production Kubernetes clusters, with a documented break-glass process?
• Is secrets management handled exclusively via ESO or equivalent (no base64-encoded secrets in Kubernetes manifests or git)?
• Are per-namespace RBAC configurations provisioned automatically on namespace creation, with no service accounts bound to cluster-admin?
• Are default-deny network policies in place per namespace, with explicit allow rules for all known service dependencies?
• Is there a documented SBOM generation and storage process for all production container images, satisfying supply chain compliance requirements?

Example use cases

• SOC2 compliance via platform guardrails: SaaS company with 40 engineers faces annual SOC2 Type II audit; platform team implements Gatekeeper policies (no root, required labels, resource limits), Cosign image signing, and ESO secrets management as platform defaults; all 25 production services are automatically compliant; audit evidence (SBOM registry, image signatures in Rekor, Gatekeeper audit reports) is auto-generated; audit prep time drops from 3 weeks to 3 days.
• Supply chain security after incident: Organisation discovers a compromised Docker Hub image was running in staging; post-incident review mandates that all images must be built by internal CI and signed with Cosign; Cosign policy controller is deployed; unsigned images are rejected at admission; within 4 weeks all services use internal base images; zero external image incidents since deployment.
• Secrets hygiene across 60 services: Platform team discovers 30% of services have database passwords as plain-text environment variables in Kubernetes Deployments (stored in git); ESO rollout over 8 weeks migrates all secrets to AWS Secrets Manager with access logging; git history is purged using BFG; all future secrets are provisioned via the ESO golden path template; zero secrets-in-git findings in subsequent audits.

Related patterns

• Internal Developer Platform — platform security controls are delivered as a component of the IDP, not as a separate security programme.
• Platform APIs and Abstractions — Gatekeeper and RBAC templates are applied at the Kubernetes API layer, integrating with the platform API infrastructure.
• Paved Roads and Golden Paths — security controls (image signing, SBOM generation) are embedded in golden path CI pipeline templates, making secure behaviour the default path.

Further reading

• OPA Gatekeeper Documentation — Gatekeeper Docs
• Cosign Signing Overview — Sigstore Docs
• External Secrets Operator Overview — ESO Docs