Skip to main content
🎀 Speaking at KubeCon EU 2026 Lessons Learned Orchestrating Multi-Tenant GPUs on OpenShift AI View Session
🎀 Speaking at Red Hat Summit 2026 GPUs take flight: Safety-first multi-tenant Platform Engineering with NVIDIA and OpenShift AI Learn More
SOC 2 compliance for cloud-native
DevOps

SOC 2 Compliance for Cloud-Native Applications Guide

A practical engineering guide to SOC 2 compliance for Kubernetes-based applications. Automate evidence collection, implement controls, and pass audits.

LB
Luca Berton
Β· 1 min read

SOC 2 compliance in cloud-native environments is achievable without sacrificing engineering velocity. The key is building compliance into your platform rather than bolting it on as an afterthought.

SOC 2 and Cloud Native

SOC 2 Trust Service Criteria map naturally to cloud-native practices:

  • Security β€” RBAC, network policies, encryption
  • Availability β€” redundancy, auto-scaling, disaster recovery
  • Processing Integrity β€” CI/CD pipelines, automated testing
  • Confidentiality β€” secrets management, data classification
  • Privacy β€” data handling, retention policies

Infrastructure as Evidence

The advantage of cloud-native: your infrastructure is code. Code is auditable. Every Terraform module, Ansible playbook, and Kubernetes manifest serves as compliance evidence.

# This NetworkPolicy IS your compliance evidence
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: database-isolation
  annotations:
    compliance.soc2/control: "CC6.1"
    compliance.soc2/description: "Database access restricted to app tier"
spec:
  podSelector:
    matchLabels:
      tier: database
  ingress:
    - from:
        - podSelector:
            matchLabels:
              tier: application

Automated Compliance Checks

Use Policy as Code to enforce SOC 2 controls continuously:

# Kyverno policy for SOC 2 CC6.1 (logical access)
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: require-security-context
spec:
  validationFailureAction: enforce
  rules:
    - name: require-non-root
      match:
        resources:
          kinds: ["Pod"]
      validate:
        message: "SOC 2 CC6.1: Containers must run as non-root"
        pattern:
          spec:
            containers:
              - securityContext:
                  runAsNonRoot: true

Secrets Management

SOC 2 requires proper handling of credentials. Use Vault or External Secrets with automatic rotation:

apiVersion: external-secrets.io/v1beta1
kind: ExternalSecret
metadata:
  name: database-credentials
spec:
  refreshInterval: 1h
  secretStoreRef:
    name: vault-backend
    kind: SecretStore
  target:
    name: db-creds
  data:
    - secretKey: password
      remoteRef:
        key: secret/data/database
        property: password

Audit Logging

Every action on your cluster must be logged. Enable Kubernetes audit logging:

apiVersion: audit.k8s.io/v1
kind: Policy
rules:
  - level: RequestResponse
    resources:
      - group: ""
        resources: ["secrets", "configmaps"]
  - level: Metadata
    resources:
      - group: "apps"
        resources: ["deployments"]

Ship audit logs to immutable storage. SOC 2 auditors will ask for 12 months of access logs.

Supply Chain Controls

SLSA framework and Sigstore provide the container signing and verification that SOC 2 CC8.1 (change management) requires. Every deployment artifact should be signed, verified, and traceable to a specific commit.

The Compliance Platform

Build compliance into your internal developer platform. When developers create a new service through your platform, it should automatically include security contexts, network policies, audit logging, and secrets management.

Compliance should be the default, not a checklist. Platform engineering makes this possible.

Luca Berton Ansible Pilot Ansible by Example Open Empower K8s Recipes Terraform Pilot CopyPasteLearn ProteinLens TechMeOut