BSI C5 -- Cloud Computing Compliance Criteria Catalogue¶
Authorised application boundary
Authorised application code is trusted. An authorised app can send out a secret it has copied or encoded. Current content checks do not provide a general guarantee against this disclosure or a malicious authorised app. Memory-read tests and a Ready agent do not prove copied/encoded-secret exfiltration prevention. Enforced NetworkPolicy can restrict destinations, but allowed traffic remains a channel. See Security Model.
Workload identity and direct store-login boundary
In direct mode, OpenBao authenticates the ServiceAccount and namespace, not the injected wrapper. Anyone who can run a pod as the application's ServiceAccount can request a matching audience-bound JWT, log in to any store role bound to that identity, and read the records its policies allow. Node root can steal the projected JWT and do the same. CloudTaser does not bind direct store release to the injected wrapper. This limit remains unresolved. Blocking exec or protecting process memory does not block a separate store login. Port/bootstrap attestation claims do not apply to direct-mode logins.
Use one workload per identity: a dedicated ServiceAccount and exact-record store policy for each app. Restrict who can create or change workloads using that ServiceAccount, including controller templates, through Kubernetes RBAC and admission policy. Namespace access alone is not isolation between apps sharing an SA. Audience checks, shorter JWT lifetimes and source CIDRs limit some replay; they do not establish wrapper identity or stop node root. Confidentiality claims on this page do not cover this credential-acquisition path.
One workload per identity applies on both direct and Port paths. Denial of a second same-identity workload on Port has not been established; a different-ServiceAccount reader test does not prove that denial.
Mapping, not certification
This document maps cloudtaser's technical controls to the named framework's requirements. It is evidence you can present to your auditor, not a cloudtaser certification. Certification is an outcome of your auditor's own review of your deployment (which may use cloudtaser's controls as supporting input).
Third-party audit roadmap: tracked in third-party audit roadmap. Target: Q2 2026. Until the audit completes, cloudtaser ships with deliberately-documented gaps rather than certification claims.
What this document IS / IS NOT¶
This is:
- A mapping of cloudtaser technical controls to framework requirements
- Evidence you can include in your auditor's evidence package
- A starting point for your DPIA / compliance narrative
This is NOT:
- A cloudtaser framework certification
- A substitute for your own audit/attestation/assessment
- Legal advice
Use this to accelerate your audit preparation, not to replace audit evidence.
Framework Overview¶
Full name: Cloud Computing Compliance Criteria Catalogue (C5:2020) Issued by: BSI (Bundesamt fur Sicherheit in der Informationstechnik -- Federal Office for Information Security, Germany) Current version: C5:2020 (revised from C5:2016) Type: Audited attestation standard for cloud service providers
The BSI C5 catalogue defines a minimum security baseline for cloud computing. It is widely used in Germany and increasingly across the EU as proof of cloud security maturity. C5 attestation is a prerequisite for cloud providers serving German federal agencies, and it is strongly recommended for providers serving regulated industries (banking, insurance, healthcare) in Germany.
Who Must Comply¶
- Cloud service providers serving the German public sector (federal, state, municipal)
- Cloud providers serving German regulated enterprises (financial services, critical infrastructure)
- Increasingly referenced by German enterprise procurement as a minimum requirement
Structure¶
C5:2020 contains 121 criteria organized into 17 requirement domains. Each criterion specifies a basic requirement and, for processing highly confidential data, an additional requirement. Attestation is performed by independent auditors under ISAE 3402 / ISAE 3000.
Relevant C5 Domains and cloudtaser Mapping¶
OIS -- Organizational Information Security¶
| C5 Criterion | Requirement Summary | cloudtaser Mapping | Component |
|---|---|---|---|
| OIS-01 | Management responsibility for information security | cloudtaser provides quantifiable security metrics via protection scores. cloudtaser-cli target audit generates reports for management review |
CLI |
| OIS-02 | Information security management system | Protection scores and audit reports integrate into the ISMS as evidence of runtime secret protection | CLI, Operator |
| OIS-04 | Separation of duties | ServiceAccount/namespace role bindings and exact-record policies limit store access; direct login is not bound to the wrapper or Deployment. See the identity caveat above | Operator, eBPF |
SP -- Security Policies¶
| C5 Criterion | Requirement Summary | cloudtaser Mapping | Component |
|---|---|---|---|
| SP-01 | Documentation of security policies | cloudtaser's annotation-based configuration (secretstore.cloudtaser.io/inject, secretstore.cloudtaser.io/secret-paths) provides declarative, auditable security policy |
Operator |
| SP-02 | Review and approval of policies | cloudtaser-cli target validate checks policy configuration against best practices. GitOps workflows (ArgoCD) provide approval trails for policy changes |
CLI |
IDM -- Identity and Access Management¶
| C5 Criterion | Requirement Summary | cloudtaser Mapping | Component |
|---|---|---|---|
| IDM-01 | Identity and access management policy | ServiceAccount/namespace role bindings and exact-record policies limit store access; direct login is not bound to the wrapper or Deployment. See the identity caveat above | Wrapper, Operator |
| IDM-02 | User registration and de-registration | Pod lifecycle manages access: secrets are only available while the pod is running with valid ServiceAccount binding. Pod deletion terminates access | Operator |
| IDM-03 | Provisioning of user access | The mutating webhook controls which pods receive secret injection based on annotation policy. Access is provisioned declaratively via Kubernetes manifests | Operator |
| IDM-06 | Privileged access management | Active BPF LSM denies covered procfs/ptrace read paths. Unrestricted node root, arbitrary kernel code and separate store logins remain outside that guarantee | eBPF |
| IDM-08 | Secure log-on procedures | OpenBao authentication uses short-lived Kubernetes ServiceAccount tokens with audience binding. Tokens are stripped from the child process environment after authentication | Wrapper |
| IDM-10 | Access to source code and program libraries | Not directly addressed by cloudtaser | -- |
CRY -- Cryptography and Key Management¶
| C5 Criterion | Requirement Summary | cloudtaser Mapping | Component |
|---|---|---|---|
| CRY-01 | Policy on use of cryptographic controls | cloudtaser enforces a consistent encryption model: TLS for transit, memfd_secret/mlock for secrets in use, AES-256-GCM for data at rest (S3 proxy) |
Wrapper, S3 Proxy |
| CRY-02 | Encryption of data in transit | All OpenBao communication uses TLS 1.2+ (mTLS when configured). Secrets are never transmitted in plaintext | Wrapper |
| CRY-03 | Encryption of data at rest | S3 proxy provides client-side AES-256-GCM encryption before data reaches cloud storage. Encryption keys remain in EU-hosted OpenBao | S3 Proxy |
| CRY-04 | Key management | Encryption keys are managed in the EU-hosted OpenBao (OpenBao). Key rotation is supported via cloudtaser-cli target rotate. Keys never leave EU jurisdiction |
Wrapper, S3 Proxy |
PS -- Physical Security¶
| C5 Criterion | Requirement Summary | cloudtaser Mapping | Component |
|---|---|---|---|
| PS-01 through PS-05 | Physical security of data centers | cloudtaser does not manage physical security. However, memfd_secret removes secret pages from the kernel direct map, providing protection against physical memory access (cold boot, DMA) on supported kernels. Confidential computing (AMD SEV-SNP) adds hardware-level memory encryption |
eBPF, Wrapper |
OS -- Operational Security¶
| C5 Criterion | Requirement Summary | cloudtaser Mapping | Component |
|---|---|---|---|
| OS-05 | Vulnerability management | cloudtaser-cli target discover identifies workloads using insecure Kubernetes Secrets (stored in etcd, accessible to the cloud provider). Each represents a data sovereignty vulnerability |
CLI |
| OS-06 | Logging and monitoring | eBPF agent generates security events for all blocked operations: SECRET_LEAK, PROCMEM_READ, ENVIRON_READ, PTRACE_DENIED, MODULE_LOAD, BPF_LOAD. Events integrate with SIEM via standard log collection |
eBPF |
| OS-07 | Monitoring of event logs | Protection scores provide continuous monitoring. cloudtaser-cli target audit produces scheduled compliance reports for log review |
CLI |
CS -- Communication Security¶
| C5 Criterion | Requirement Summary | cloudtaser Mapping | Component |
|---|---|---|---|
| CS-01 | Network security management | cloudtaser-cli target netpol generates Kubernetes NetworkPolicies that restrict pod communication to the OpenBao endpoint, limiting the network attack surface |
CLI |
| CS-02 | Security of network services | OpenBao communication is over TLS/mTLS. The wrapper validates OpenBao TLS certificates. Network policies prevent lateral movement | Wrapper |
PI -- Portability and Interoperability¶
| C5 Criterion | Requirement Summary | cloudtaser Mapping | Component |
|---|---|---|---|
| PI-01 | Portability of data and services | cloudtaser is cloud-agnostic. Secrets are stored in a portable EU OpenBao (OpenBao), not locked to any cloud provider's secret management service. Switching cloud providers does not require re-engineering secret management | Wrapper, Operator |
| PI-02 | Interoperability standards | cloudtaser uses standard Kubernetes APIs (admission webhooks, ServiceAccounts, annotations). It works on any conformant Kubernetes distribution | Operator |
SSO -- Supplier Relationships¶
| C5 Criterion | Requirement Summary | cloudtaser Mapping | Component |
|---|---|---|---|
| SSO-01 | Information security in supplier relationships | The customer controls store access and key custody. CloudTaser reduces specific delivery/read-path exposure; provider risk still includes credential theft, application disclosure, guest-kernel compromise and the compute substrate. Supplier review and contractual controls remain necessary | All |
| SSO-02 | Monitoring of supplier services | cloudtaser-cli target audit monitors protection coverage and detects drift. eBPF events detect anomalous access patterns from the infrastructure layer |
CLI, eBPF |
DEV -- Procurement, Development and Maintenance¶
| C5 Criterion | Requirement Summary | cloudtaser Mapping | Component |
|---|---|---|---|
| DEV-01 | Secure development policy | cloudtaser-cli target discover scans for insecure secret references in CI/CD pipelines. cloudtaser-cli target validate verifies correct configuration before deployment |
CLI |
| DEV-05 | System security testing | Protection scores and audit reports verify that security controls are functioning correctly in production | CLI |
COM -- Compliance and Data Privacy¶
| C5 Criterion | Requirement Summary | cloudtaser Mapping | Component |
|---|---|---|---|
| COM-01 | Compliance with legal and regulatory requirements | cloudtaser provides the technical layer for GDPR Art. 32 compliance, Schrems II supplementary measures, and NIS2 Art. 21 requirements. cloudtaser-cli target audit generates evidence packages |
CLI, All |
| COM-02 | Data protection | The customer operates the EU OpenBao store. Delivery creates no Kubernetes Secret for the value; tested API-object and log sweeps found no matches for the tested values. This does not prove absence from application copies, disk or swap; identity and runtime caveats above still apply | Wrapper, eBPF |
Component Coverage Matrix¶
| cloudtaser Component | C5 Domains Addressed |
|---|---|
| Operator (webhook injection) | OIS, SP, IDM, PI |
| Wrapper (secret delivery) | CRY, IDM, CS, PI, COM |
| eBPF (runtime enforcement) | IDM, OS, PS, SSO |
| S3 Proxy (client-side encryption) | CRY, COM |
| DB Proxy (transparent encryption) | CRY, COM |
| CLI (audit, validate, discover) | OIS, SP, OS, CS, DEV, SSO, COM |
Gaps and Limitations¶
cloudtaser is a runtime data protection product, not a full cloud security platform. The following C5 domains are outside cloudtaser's scope:
| C5 Domain | Gap | Mitigation |
|---|---|---|
| PS (Physical Security) | cloudtaser does not control data center physical security | Use a cloud provider with C5 attestation for the infrastructure layer. cloudtaser's memfd_secret provides defense-in-depth against physical memory access |
| AM (Asset Management) | cloudtaser does not perform general IT asset management | Use Kubernetes-native asset inventory tools. cloudtaser-cli target discover covers secret-related assets |
| BCM (Business Continuity Management) | cloudtaser does not manage business continuity planning | OpenBao high availability and cloudtaser's cloud-agnostic design support BCM, but planning is the customer's responsibility |
| HR (Human Resources Security) | cloudtaser does not manage HR security processes | Organizational measure, outside product scope |
| RMG (Risk Management) | cloudtaser contributes to risk management but does not replace an enterprise risk management framework | Protection scores quantify one dimension of risk. Integrate with enterprise GRC tooling |
C5 is primarily a provider attestation
C5 attestation is typically sought by cloud service providers, not their customers. cloudtaser helps customers of non-C5-attested providers (or providers whose C5 scope does not cover all controls) achieve equivalent protection for secrets through technical enforcement. For cloudtaser SaaS customers, cloudtaser's own C5-relevant controls can be included in their provider's attestation scope.
Audit Evidence¶
cloudtaser produces evidence suitable for C5 audits:
# Generate compliance audit report
cloudtaser-cli target audit --secretstore-address https://vault.eu.example.com
# JSON output for audit evidence
cloudtaser-cli target audit --secretstore-address https://vault.eu.example.com -o json
The audit report provides:
- Protected vs. unprotected workload inventory (OIS, COM)
- eBPF enforcement coverage per node (OS, IDM)
- Protection scores per workload (OIS, DEV)
- OpenBao connectivity and TLS verification (CRY, CS)
- Orphaned Kubernetes Secrets in etcd (COM, OS)