BIO -- Baseline Informatiebeveiliging Overheid¶
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: Baseline Informatiebeveiliging Overheid (BIO) -- Government Information Security Baseline Issued by: Dutch government (CIP framework, published in the Government Gazette / Staatscourant) Current version: BIO2 v1.3 (published March 2026, effective immediately) Based on: NEN-EN-ISO/IEC 27001:2022 and NEN-EN-ISO/IEC 27002:2022 Type: Mandatory self-regulation for Dutch government agencies
BIO is the mandatory information security framework for all layers of Dutch government: central government (Rijksoverheid), provinces, municipalities, and water authorities. It defines minimum security requirements based on ISO 27001/27002 with additional government-specific controls. BIO2 (the current version) aligns with ISO 27002:2022.
Who Must Comply¶
- Dutch central government agencies (ministries, executive agencies)
- All 12 Dutch provinces
- All 342 Dutch municipalities
- All 21 water authorities (waterschappen)
- Suppliers and service providers to Dutch government (via contractual requirements)
Related Framework: BIO Thema-uitwerking Clouddiensten¶
The BIO Thema-uitwerking Clouddiensten (Cloud Services Theme Elaboration) is a separate, voluntary guidance document that helps government organizations formulate controls when using cloud services. It supplements BIO with cloud-specific requirements. cloudtaser addresses controls from both BIO and the cloud theme elaboration.
BIO Control Areas and cloudtaser Mapping¶
BIO2 follows the ISO 27002:2022 structure with government-specific additions. The control numbering below follows the ISO 27002:2022 structure as used in BIO2.
5 -- Organizational Controls¶
| BIO Control | Description | cloudtaser Mapping | Component |
|---|---|---|---|
| 5.1 -- Information security policies | Policies for information security must be defined and approved | cloudtaser's annotation-based configuration provides declarative, version-controlled security policy for secret management. GitOps workflows provide approval trails | Operator |
| 5.2 -- Information security roles | Roles and responsibilities must be defined | The operator controls injection policy, OpenBao controls access policy, eBPF enforces runtime policy. Separation of duties is architecturally enforced | Operator, Wrapper, eBPF |
| 5.10 -- Acceptable use of information | Rules for acceptable use of information and assets must be defined | Configured runtime checks cover specific paths and patterns. An authorised app can disclose copied or encoded secrets; no general prevention guarantee is established. Enforced egress policy narrows destinations but allowed channels remain | eBPF |
| 5.15 -- Access control | Rules for access control must be established | 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, Wrapper, eBPF |
| 5.23 -- Information security for cloud services | Information security requirements for cloud services must be defined | cloudtaser directly addresses the core cloud security concern: preventing the cloud provider from accessing government secrets | All |
| 5.31 -- Legal requirements | Legal, statutory, and regulatory requirements must be identified and addressed | cloudtaser provides technical supplementary measures for GDPR Art. 32, Schrems II, NIS2, and the EU Data Act | All |
8 -- Technological Controls¶
| BIO Control | Description | cloudtaser Mapping | Component |
|---|---|---|---|
| 8.1 -- User endpoint devices | Information stored on, processed by, or accessible via endpoint devices must be protected | Not directly addressed (cloudtaser protects server-side secrets in Kubernetes pods) | -- |
| 8.2 -- Privileged access rights | The allocation and use of privileged access rights must be restricted and managed | Active BPF LSM denies covered procfs/ptrace read paths. Unrestricted node root, arbitrary kernel code and separate store logins remain outside that guarantee | eBPF |
| 8.3 -- Information access restriction | Access to information must be restricted according to the access control 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 | Operator, Wrapper |
| 8.5 -- Secure authentication | Secure authentication technologies and procedures must be established | OpenBao Kubernetes auth uses short-lived, audience-bound ServiceAccount tokens. Tokens are stripped from the child process environment after authentication | Wrapper |
| 8.7 -- Protection against malware | Protection against malware must be implemented | Configured runtime checks cover specific paths and patterns. An authorised app can disclose copied or encoded secrets; no general prevention guarantee is established. Enforced egress policy narrows destinations but allowed channels remain | eBPF |
| 8.9 -- Configuration management | Configurations must be established, documented, implemented, monitored, and reviewed | cloudtaser-cli target validate verifies correct configuration. cloudtaser-cli target audit detects drift. Protection scores provide continuous monitoring |
CLI |
| 8.10 -- Information deletion | Information stored in systems, devices, or media must be deleted when no longer required | Delivery creates no Kubernetes Secret for the value. Wrapper memory handling does not establish deletion of application copies, logs, disk/swap data or store backups; define and verify their retirement separately | Wrapper |
| 8.11 -- Data masking | Data masking must be used according to the access control policy | Masking keys can be stored in the customer-operated EU OpenBao and delivered to the application without a Kubernetes Secret for the value. Application use/copies and key access through shared identities remain separate risks | Wrapper |
| 8.12 -- Data leakage prevention | Data leakage prevention measures must be applied | Configured runtime checks cover specific paths and patterns. An authorised app can disclose copied or encoded secrets; no general prevention guarantee is established. Enforced egress policy narrows destinations but allowed channels remain | eBPF |
| 8.15 -- Logging | Logs must be produced, stored, protected, and analyzed | eBPF generates security events for all blocked operations. OpenBao audit log records all secret fetch operations. Events integrate with SIEM via standard log collection | eBPF |
| 8.16 -- Monitoring activities | Networks, systems, and applications must be monitored for anomalous behavior | Published source catalogues 37 kprobe syscall programs; qualify actual monitoring and denial per path. Protection scores provide continuous security posture monitoring. cloudtaser-cli target audit runs scheduled compliance checks |
eBPF, CLI |
| 8.20 -- Networks security | Networks and network devices must be secured | cloudtaser-cli target netpol generates Kubernetes NetworkPolicies restricting pod communication to the OpenBao endpoint. This limits network attack surface |
CLI |
| 8.24 -- Use of cryptography | Rules for effective use of cryptography must be defined and implemented | All OpenBao communication uses TLS 1.2+. Secrets are protected in memory using memfd_secret and mlock. S3 proxy uses AES-256-GCM for data at rest |
Wrapper, S3 Proxy |
| 8.25 -- Secure development lifecycle | Rules for secure development must be established | cloudtaser-cli target discover scans for insecure secret references before production deployment. cloudtaser-cli target validate verifies configuration in CI/CD pipelines |
CLI |
| 8.28 -- Secure coding | Secure coding principles must be applied | cloudtaser eliminates the most common secret handling vulnerability: storing secrets in Kubernetes Secrets (accessible via etcd). Developers use OpenBao paths instead of hardcoded secrets | Operator, Wrapper |
BIO Cloud Theme Elaboration (Thema-uitwerking Clouddiensten)¶
The cloud theme elaboration adds cloud-specific controls:
| Cloud Control | Description | cloudtaser Mapping | Component |
|---|---|---|---|
| CLD-01 -- Cloud security architecture | Security architecture for cloud deployments must be documented | cloudtaser's architecture (webhook injection, memfd secret delivery, eBPF enforcement) is documented and verifiable via cloudtaser-cli target validate |
All |
| CLD-02 -- Cloud data protection | Data processed in the cloud must be protected against unauthorized access by the provider | Delivery creates no Kubernetes Secret for the value and runtime enforcement covers specific read paths. Application copies, raw store login and guest-kernel compromise remain outside any blanket provider-confidentiality guarantee | Wrapper, eBPF |
| CLD-03 -- Cloud key management | Cryptographic keys for cloud data must be managed by the government organization, not the provider | The government organization or its EU delegate operates OpenBao and controls policies and key custody. cloudtaser-cli target rotate supports rotation operations; runtime copies and shared-identity access still need separate controls |
Wrapper, S3 Proxy |
| CLD-04 -- Cloud exit strategy | A viable exit strategy from the cloud provider must exist | cloudtaser is cloud-agnostic. Secrets are in a portable OpenBao, not locked to any provider's proprietary service | Wrapper, Operator |
Component Coverage Matrix¶
| cloudtaser Component | BIO Controls Addressed |
|---|---|
| Operator (webhook injection) | 5.1, 5.2, 5.15, 8.3, 8.28, CLD-04 |
| Wrapper (secret delivery) | 5.15, 8.3, 8.5, 8.10, 8.11, 8.24, CLD-02, CLD-03, CLD-04 |
| eBPF (runtime enforcement) | 5.2, 5.10, 5.15, 8.2, 8.7, 8.12, 8.15, 8.16, CLD-02 |
| S3 Proxy (client-side encryption) | 8.24, CLD-03 |
| DB Proxy (transparent encryption) | 8.24, CLD-03 |
| CLI (audit, validate, discover) | 5.1, 8.9, 8.16, 8.20, 8.25 |
BIO Classification Levels¶
BIO uses three classification levels for government information. cloudtaser's relevance increases with classification level:
| Level | Description | cloudtaser Relevance |
|---|---|---|
| BBN1 (Basis) | Low impact if compromised. Standard government information | cloudtaser provides defense-in-depth. Recommended for workloads on US cloud providers |
| BBN2 (Midden) | Medium impact. Confidential government information | cloudtaser strongly recommended. Protection scores must meet minimum thresholds. eBPF enforcement should be active |
| BBN3 (Hoog) | High impact. Highly confidential / state secret | cloudtaser is essential. Maximum protection score required. Full eBPF enforcement (synchronous blocking, which requires a kernel with CONFIG_BPF_KPROBE_OVERRIDE=y; see Kernel Compatibility). Consider confidential computing (SEV-SNP) as additional layer |
Gaps and Limitations¶
| BIO Area | Gap | Mitigation |
|---|---|---|
| Physical security (8.12 physical) | cloudtaser does not control physical security of data centers | Use a cloud provider with DigiD-assessed or BIO-compliant data centers for the infrastructure layer. memfd_secret provides defense-in-depth against physical memory access |
| Human resources (6.x) | cloudtaser does not manage HR security processes | Organizational measure, outside product scope |
| Asset management (5.9) | cloudtaser does not perform general IT asset management | Use Kubernetes-native asset inventory. cloudtaser-cli target discover covers secret-related assets |
| Incident management (5.24-5.28) | cloudtaser detects incidents but does not replace an incident management process | eBPF events feed into SIEM and incident management tooling. The incident response process is the organization's responsibility |
| Business continuity (5.29-5.30) | cloudtaser does not manage business continuity planning | OpenBao HA and cloud-agnostic portability support BCP. Planning is the organization's responsibility |
| Endpoint security (8.1) | cloudtaser protects server-side secrets, not endpoint devices | Outside scope. cloudtaser operates in Kubernetes clusters, not on end-user devices |
| BBN3 / state secrets | For BBN3 data, additional measures beyond cloudtaser may be required (e.g., AIVD-certified HSMs, government-operated infrastructure) | cloudtaser provides a strong technical baseline. For BBN3, combine with government-specific HSM requirements and potentially on-premises deployment |
BIO is a government framework
BIO applies to Dutch government agencies, not to commercial enterprises. However, suppliers to the Dutch government are often contractually required to meet BIO requirements. cloudtaser helps suppliers demonstrate that their cloud-hosted services protect government data from the cloud provider.
Audit Evidence¶
cloudtaser produces evidence suitable for BIO audits and ENSIA (Eenduidige Normatiek Single Information Audit) assessments:
# 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 (5.23, CLD-02)
- Protection scores per workload (8.9, 8.16)
- eBPF enforcement coverage per node (8.2, 8.12)
- EU OpenBao connectivity verification (CLD-03)
- Orphaned Kubernetes Secrets in etcd (8.10, CLD-02)
- TLS/mTLS configuration details (8.24)