From 48d9ab3669a1036d754c5bd5ba1de6dcbf916846 Mon Sep 17 00:00:00 2001 From: Yannik Daellenbach Date: Mon, 8 Sep 2025 18:01:07 +0200 Subject: [PATCH 01/12] Init ADR for managed OpenBao on AppCat --- .../ROOT/pages/adr/0049-managed-openbao.adoc | 207 ++++++++++++++++++ docs/modules/ROOT/partials/nav-adrs.adoc | 3 +- templates/adr/cookiecutter.json | 4 +- 3 files changed, 211 insertions(+), 3 deletions(-) create mode 100644 docs/modules/ROOT/pages/adr/0049-managed-openbao.adoc diff --git a/docs/modules/ROOT/pages/adr/0049-managed-openbao.adoc b/docs/modules/ROOT/pages/adr/0049-managed-openbao.adoc new file mode 100644 index 00000000..3668e6ba --- /dev/null +++ b/docs/modules/ROOT/pages/adr/0049-managed-openbao.adoc @@ -0,0 +1,207 @@ += ADR 0043 - Managed OpenBao Service Implementation +:adr_author: Yannik Dällenbach +:adr_owner: Schedar/bespinian +:adr_reviewers: Schedar +:adr_date: 2025-01-13 +:adr_upd_date: 2025-01-13 +:adr_status: draft +:adr_tags: service,openbao,secret-management + +include::partial$adr-meta.adoc[] + +[NOTE] +.Summary +==== +This ADR outlines the implementation of a managed OpenBao service on the AppCat platform to provide secret mamanagement capabilities to customers. +This builds upon the suggestion of xref:adr/0024-product-choice-for-secret-management.adoc[ADR 0024] to use OpenBao as secret and PKI management solution. +==== + +== Context + +Following the suggestion in ADR 0024 to use OpenBao for secret management, we need to implement it as a managed service within the AppCat ecosystem. OpenBao provides: + +- Secret storage with REST API +- Vault API compatibility +- Open-source license with Linux Foundation backing +- Self-hostable deployment model + +The service must integrate with the existing AppCat patterns including: + +- Crossplane-based provisioning +- Managed namespace deployment model +- User-workload monitoring integration +- Backup and maintenance automation +- SLA monitoring and reporting + +== Requirements + +=== Functional Requirements + +* **Secret Management**: Store, retrieve, and manage secrets via REST API +* **API Compatibility**: Maintain Vault API compatibility for existing tooling +* **High Availability**: Support clustered deployment for production workloads +* **Authentication**: Integration with OIDC + +=== Operational Requirements + +* **Backup & Recovery**: Automated backup of secret data +* **Monitoring**: SLA metrics, capacity alerts, and operational dashboards +* **Maintenance**: Automated security updates and version upgrades +* **Scaling**: Horizontal scaling capabilities for high-throughput scenarios +* **Security**: Encryption at rest, TLS in transit, audit logging + +== Proposals + +=== Proposal 1: Helm Chart with External Storage + +Deploy OpenBao using the official Helm chart with external storage backends (PostgreSQL). + +**Implementation:** + +- Use `provider-helm` to deploy OpenBao Helm chart +- PostgreSQL backend for secret storage (leveraging existing `VSHNPostgreSQL`) +- Initialization through composition functions + +**Advantages:** + +- Leverages existing PostgreSQL infrastructure +- Official Helm chart provides production-ready deployment +- Separation of compute and storage for better scaling +- Familiar AppCat deployment patterns + +**Disadvantages:** + +- Additional complexity in managing external dependencies +- Potential performance overhead with external storage + +=== Proposal 2: Integrated Deployment with Local Storage + +Deploy OpenBao with integrated storage using Raft consensus. + +**Implementation:** + +- Use `provider-helm` to deploy OpenBao Helm chart +- Raft storage backend for simplicity +- Built-in clustering for high availability + +**Advantages:** + +- Simplified deployment with fewer external dependencies +- Built-in consensus and replication + +**Disadvantages:** + +- Raft cluster management overhead + +=== Proposal 3: Operator-Based Deployment + +Develop or adopt an OpenBao operator for Kubernetes-native management. + +**Implementation:** + +- Custom operator following AppCat patterns +- CRDs for vault configuration and policies +- Automated lifecycle management +- Native Kubernetes integration + +**Advantages:** + +- Full Kubernetes-native experience +- Automated day-2 operations +- Extensible for future features +- Better integration with AppCat framework + +**Disadvantages:** + +- High development effort +- Additional operational complexity +- Maintenance burden for custom operator + +== Decision + +**Proposal 2: Helm Chart with Internal Storage** + +We choose to implement OpenBao using the official Helm chart with integrated Raft storage. + +### Implementation Details + +**Storage Backend:** + +- Primary: Raft consensus storage for built-in clustering +- Leverage existing AppCat Backup mechanisms (K8sup) +- Self-contained storage eliminates external dependencies + +**Deployment Architecture:** + +TODO + +```yaml +apiVersion: vshn.appcat.vshn.io/v1 +kind: VSHNOpenBao +metadata: + name: my-bao +spec: + parameters: + service: + version: "2.0.0" + replicas: 3 + storage: + backup: + enabled: true + schedule: "0 2 * * *" + snapshots: true + monitoring: + enabled: true +``` + +**Key Components:** + +1. **OpenBao Cluster**: 3-node HA deployment with Raft consensus +2. **Raft Storage**: Built-in distributed storage backend +3. **Backup Storage**: `VSHNObjectBucket` for Raft snapshots using K8sup +4. **Monitoring**: Custom SLI exporter and Prometheus integration + +**Security Model:** + +- TLS encryption for all communications +- Kubernetes service account integration +- RBAC policies managed through OpenBao +- Audit logging to persistent storage +- Auto-unseal configuration for cluster bootstrap + +== Consequences + +**Positive** + +- Simplified deployment with fewer external dependencies +- Built-in consensus and replication reduces operational complexity +- Self-contained backup mechanisms using Raft snapshots +- Leverages official OpenBao Helm chart for production readiness +- Eliminates external storage dependency management + +**Negative** + +- Raft cluster management requires specialized knowledge +- Limited to OpenBao's built-in storage capabilities +- Potential storage scaling limitations compared to external databases +- No feature parity with HashiCorp Vault Enterprise + +**Operational Impact** + +- Simplified service deployment with reduced external dependencies +- Raft snapshot management and restoration procedures +- Need for OpenBao and Raft consensus expertise in operations team +- Integration testing with existing AppCat services +- TLS certificate lifecycle management (renewal, rotation) +- Auto-unseal configuration and cluster bootstrap management +- Raft cluster health monitoring and node management +- Audit log management and compliance reporting +- ServiceMonitor configuration for Prometheus integration +- Snapshot-based backup validation and testing + +**Customer Benefits** + +- Self-hosted alternative to cloud secret management services +- Kubernetes-native secret injection patterns +- Vault API compatibility for existing applications and tooling +- Compliance with data sovereignty requirements \ No newline at end of file diff --git a/docs/modules/ROOT/partials/nav-adrs.adoc b/docs/modules/ROOT/partials/nav-adrs.adoc index cd51872e..2f7cffb3 100644 --- a/docs/modules/ROOT/partials/nav-adrs.adoc +++ b/docs/modules/ROOT/partials/nav-adrs.adoc @@ -45,4 +45,5 @@ ** xref:adr/0045-service-orchestration-crossplane-2-0.adoc[] ** xref:adr/0046-secret-management-framework-2-0.adoc[] ** xref:adr/0047-service-maintenance-and-upgrades-framework-2-0.adoc[] -** xref:adr/0048-evaluating-vector-databases-as-appcat-services.adoc[] \ No newline at end of file +** xref:adr/0048-evaluating-vector-databases-as-appcat-services.adoc[] +** xref:adr/0049-managed-openbao.adoc[] diff --git a/templates/adr/cookiecutter.json b/templates/adr/cookiecutter.json index 0241b844..c5b5b833 100644 --- a/templates/adr/cookiecutter.json +++ b/templates/adr/cookiecutter.json @@ -1,5 +1,5 @@ { - "adr_number": "0049", + "adr_number": "0050", "full_name": "VSHNeer Name", "adr_title": "Title", "adr_reviewers": "", @@ -37,4 +37,4 @@ }, "adr_tags": "Comma separated list of tags - all lowercase" } -} \ No newline at end of file +} From b02b432ffeeac0706c1e21032cb8ddd743c5ab05 Mon Sep 17 00:00:00 2001 From: Yannik Daellenbach Date: Tue, 23 Sep 2025 09:58:42 +0200 Subject: [PATCH 02/12] Use description lists instead of bold title and list combination --- .../ROOT/pages/adr/0049-managed-openbao.adoc | 32 +++++++++---------- 1 file changed, 16 insertions(+), 16 deletions(-) diff --git a/docs/modules/ROOT/pages/adr/0049-managed-openbao.adoc b/docs/modules/ROOT/pages/adr/0049-managed-openbao.adoc index 3668e6ba..bede58eb 100644 --- a/docs/modules/ROOT/pages/adr/0049-managed-openbao.adoc +++ b/docs/modules/ROOT/pages/adr/0049-managed-openbao.adoc @@ -56,20 +56,20 @@ The service must integrate with the existing AppCat patterns including: Deploy OpenBao using the official Helm chart with external storage backends (PostgreSQL). -**Implementation:** +Implementation:: - Use `provider-helm` to deploy OpenBao Helm chart - PostgreSQL backend for secret storage (leveraging existing `VSHNPostgreSQL`) - Initialization through composition functions -**Advantages:** +Advantages:: - Leverages existing PostgreSQL infrastructure - Official Helm chart provides production-ready deployment - Separation of compute and storage for better scaling - Familiar AppCat deployment patterns -**Disadvantages:** +Disadvantages:: - Additional complexity in managing external dependencies - Potential performance overhead with external storage @@ -78,18 +78,18 @@ Deploy OpenBao using the official Helm chart with external storage backends (Pos Deploy OpenBao with integrated storage using Raft consensus. -**Implementation:** +Implementation:: - Use `provider-helm` to deploy OpenBao Helm chart - Raft storage backend for simplicity - Built-in clustering for high availability -**Advantages:** +Advantages:: - Simplified deployment with fewer external dependencies - Built-in consensus and replication -**Disadvantages:** +Disadvantages:: - Raft cluster management overhead @@ -97,21 +97,21 @@ Deploy OpenBao with integrated storage using Raft consensus. Develop or adopt an OpenBao operator for Kubernetes-native management. -**Implementation:** +Implementation:: - Custom operator following AppCat patterns - CRDs for vault configuration and policies - Automated lifecycle management - Native Kubernetes integration -**Advantages:** +Advantages:: - Full Kubernetes-native experience - Automated day-2 operations - Extensible for future features - Better integration with AppCat framework -**Disadvantages:** +Disadvantages:: - High development effort - Additional operational complexity @@ -125,7 +125,7 @@ We choose to implement OpenBao using the official Helm chart with integrated Raf ### Implementation Details -**Storage Backend:** +Storage Backend:: - Primary: Raft consensus storage for built-in clustering - Leverage existing AppCat Backup mechanisms (K8sup) @@ -154,14 +154,14 @@ spec: enabled: true ``` -**Key Components:** +Key Components:: 1. **OpenBao Cluster**: 3-node HA deployment with Raft consensus 2. **Raft Storage**: Built-in distributed storage backend 3. **Backup Storage**: `VSHNObjectBucket` for Raft snapshots using K8sup 4. **Monitoring**: Custom SLI exporter and Prometheus integration -**Security Model:** +Security Model:: - TLS encryption for all communications - Kubernetes service account integration @@ -171,7 +171,7 @@ spec: == Consequences -**Positive** +Positive:: - Simplified deployment with fewer external dependencies - Built-in consensus and replication reduces operational complexity @@ -179,14 +179,14 @@ spec: - Leverages official OpenBao Helm chart for production readiness - Eliminates external storage dependency management -**Negative** +Negative:: - Raft cluster management requires specialized knowledge - Limited to OpenBao's built-in storage capabilities - Potential storage scaling limitations compared to external databases - No feature parity with HashiCorp Vault Enterprise -**Operational Impact** +Operational Impact:: - Simplified service deployment with reduced external dependencies - Raft snapshot management and restoration procedures @@ -199,7 +199,7 @@ spec: - ServiceMonitor configuration for Prometheus integration - Snapshot-based backup validation and testing -**Customer Benefits** +Customer Benefits:: - Self-hosted alternative to cloud secret management services - Kubernetes-native secret injection patterns From b2d5b2d5517fa2113cd5c8c376893d08e3358af0 Mon Sep 17 00:00:00 2001 From: Yannik Daellenbach Date: Fri, 26 Sep 2025 11:54:36 +0200 Subject: [PATCH 03/12] Fix spelling of management, K8up instead of K8sup and `ObjectBucket` --- docs/modules/ROOT/pages/adr/0049-managed-openbao.adoc | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/docs/modules/ROOT/pages/adr/0049-managed-openbao.adoc b/docs/modules/ROOT/pages/adr/0049-managed-openbao.adoc index bede58eb..e8bec0e0 100644 --- a/docs/modules/ROOT/pages/adr/0049-managed-openbao.adoc +++ b/docs/modules/ROOT/pages/adr/0049-managed-openbao.adoc @@ -12,7 +12,7 @@ include::partial$adr-meta.adoc[] [NOTE] .Summary ==== -This ADR outlines the implementation of a managed OpenBao service on the AppCat platform to provide secret mamanagement capabilities to customers. +This ADR outlines the implementation of a managed OpenBao service on the AppCat platform to provide secret mananagement capabilities to customers. This builds upon the suggestion of xref:adr/0024-product-choice-for-secret-management.adoc[ADR 0024] to use OpenBao as secret and PKI management solution. ==== @@ -128,7 +128,7 @@ We choose to implement OpenBao using the official Helm chart with integrated Raf Storage Backend:: - Primary: Raft consensus storage for built-in clustering -- Leverage existing AppCat Backup mechanisms (K8sup) +- Leverage existing AppCat Backup mechanisms (K8up) - Self-contained storage eliminates external dependencies **Deployment Architecture:** @@ -158,7 +158,7 @@ Key Components:: 1. **OpenBao Cluster**: 3-node HA deployment with Raft consensus 2. **Raft Storage**: Built-in distributed storage backend -3. **Backup Storage**: `VSHNObjectBucket` for Raft snapshots using K8sup +3. **Backup Storage**: `ObjectBucket` for Raft snapshots using K8up 4. **Monitoring**: Custom SLI exporter and Prometheus integration Security Model:: From c769cbbd507e55c195409d46194437c021c9c136 Mon Sep 17 00:00:00 2001 From: Yannik Daellenbach Date: Wed, 1 Oct 2025 16:51:01 +0200 Subject: [PATCH 04/12] Remove AppCat integration advantage --- docs/modules/ROOT/pages/adr/0049-managed-openbao.adoc | 1 - 1 file changed, 1 deletion(-) diff --git a/docs/modules/ROOT/pages/adr/0049-managed-openbao.adoc b/docs/modules/ROOT/pages/adr/0049-managed-openbao.adoc index e8bec0e0..e352796f 100644 --- a/docs/modules/ROOT/pages/adr/0049-managed-openbao.adoc +++ b/docs/modules/ROOT/pages/adr/0049-managed-openbao.adoc @@ -109,7 +109,6 @@ Advantages:: - Full Kubernetes-native experience - Automated day-2 operations - Extensible for future features -- Better integration with AppCat framework Disadvantages:: From bfc3d2604fe89af8e443886071fd4da8605f0747 Mon Sep 17 00:00:00 2001 From: Yannik Daellenbach Date: Wed, 1 Oct 2025 16:49:32 +0200 Subject: [PATCH 05/12] K8s integration is not part of this ADR --- docs/modules/ROOT/pages/adr/0049-managed-openbao.adoc | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/docs/modules/ROOT/pages/adr/0049-managed-openbao.adoc b/docs/modules/ROOT/pages/adr/0049-managed-openbao.adoc index e352796f..5d6c0627 100644 --- a/docs/modules/ROOT/pages/adr/0049-managed-openbao.adoc +++ b/docs/modules/ROOT/pages/adr/0049-managed-openbao.adoc @@ -163,10 +163,9 @@ Key Components:: Security Model:: - TLS encryption for all communications -- Kubernetes service account integration - RBAC policies managed through OpenBao - Audit logging to persistent storage -- Auto-unseal configuration for cluster bootstrap +- Auto-unseal configuration for OpenBao bootstrap == Consequences @@ -201,6 +200,5 @@ Operational Impact:: Customer Benefits:: - Self-hosted alternative to cloud secret management services -- Kubernetes-native secret injection patterns - Vault API compatibility for existing applications and tooling - Compliance with data sovereignty requirements \ No newline at end of file From ad71d5d9487a07cda061ecd733040226315c7eef Mon Sep 17 00:00:00 2001 From: Yannik Daellenbach Date: Mon, 6 Oct 2025 16:46:49 +0200 Subject: [PATCH 06/12] Add API specification and auto-unseal configuration to OpenBao ADR Replaces TODO deployment architecture with complete VSHNOpenBao CRD specification including service configuration, sizing, backup, monitoring, and maintenance parameters. Documents auto-unseal functionality with support for AWS KMS, Azure Key Vault, GCP KMS, and Transit providers, including AWS KMS example configuration. --- .../ROOT/pages/adr/0049-managed-openbao.adoc | 136 ++++++++++++++++-- 1 file changed, 125 insertions(+), 11 deletions(-) diff --git a/docs/modules/ROOT/pages/adr/0049-managed-openbao.adoc b/docs/modules/ROOT/pages/adr/0049-managed-openbao.adoc index 5d6c0627..02f4ab0b 100644 --- a/docs/modules/ROOT/pages/adr/0049-managed-openbao.adoc +++ b/docs/modules/ROOT/pages/adr/0049-managed-openbao.adoc @@ -130,29 +130,143 @@ Storage Backend:: - Leverage existing AppCat Backup mechanisms (K8up) - Self-contained storage eliminates external dependencies -**Deployment Architecture:** +**API Specification:** -TODO +The VSHNOpenBao CRD follows AppCat conventions (ADR 0016) with parameter groups for service configuration, sizing, backup, monitoring, and maintenance. ```yaml apiVersion: vshn.appcat.vshn.io/v1 kind: VSHNOpenBao metadata: - name: my-bao + name: my-openbao + namespace: my-namespace spec: parameters: + # Service configuration service: - version: "2.0.0" - replicas: 3 - storage: - backup: - enabled: true - schedule: "0 2 * * *" - snapshots: true - monitoring: + version: "2.1.0" # OpenBao version (enum of supported versions) + fqdn: "openbao.example.com" # Fully qualified domain name + serviceLevel: guaranteed # besteffort or guaranteed + openBaoSettings: + # Auto-unseal configuration (optional) + # Enables automatic unsealing using external key management systems + # Only one provider should be configured at a time + autoUnseal: + awsKmsSecretRef: "" # Reference to secret containing AWS KMS credentials and configuration + azureKeyVaultSecretRef: "" # Reference to secret containing Azure Key Vault credentials and configuration + gcpKmsSecretRef: "" # Reference to secret containing GCP Cloud KMS credentials and configuration + transitSecretRef: "" # Reference to secret containing connection details to another Vault/OpenBao instance + + # Number of OpenBao instances + # For guaranteed serviceLevel: must be 3 + # For besteffort serviceLevel: can be 1 or 3 + instances: 3 + + # Sizing + size: + plan: standard # Resource plan: small, standard, large + requests: + cpu: "2" + memory: "4Gi" + disk: 20Gi # Raft storage volume size per replica + storageClass: "" # Optional storage class override + + # Backup and restore configuration (using K8up) + backup: enabled: true + schedule: "0 2 * * *" # Cron schedule for Raft snapshots + retention: + keepLast: 2 + keepHourly: 2 + keepDaily: 7 + keepWeekly: 4 + keepMonthly: 3 + restore: + claimName: "" + backupName: "" + + # Maintenance window + maintenance: + dayOfWeek: Tuesday # enum: Monday-Sunday + timeOfDay: "22:00" # HH:MM format in UTC + + # Monitoring + monitoring: + alertmanagerConfigRef: "" + alertmanagerConfigSecretRef: {} + alertmanagerConfigTemplate: {} + email: "" + + # Unseal keys and root token secret reference + # This secret will contain the unseal keys and root token generated during initialization + writeUnsealKeysSecretToRef: + name: openbao-unseal-keys + namespace: "" # defaults to claim namespace +``` + +**Unseal Keys Secret:** + +The `writeUnsealKeysSecretToRef` secret contains the unseal keys and root token: + +```yaml +apiVersion: v1 +kind: Secret +metadata: + name: openbao-unseal-keys +data: + unseal-key-1: + unseal-key-2: + unseal-key-3: + unseal-key-4: + unseal-key-5: + root-token: ``` +**Auto unseal** + +Auto unseal allows OpenBao to unseal automatically without manual intervention using an external key management system. This is crucial for automated recovery and reduces operational burden. + +Supported auto-unseal providers: + +AWS KMS::: Configure using `awsKmsSecretRef` pointing to a secret containing AWS credentials and KMS key configuration +Azure Key Vault::: Configure using `azureKeyVaultSecretRef` pointing to a secret containing Azure credentials and Key Vault details +GCP Cloud KMS::: Configure using `gcpKmsSecretRef` pointing to a secret containing GCP credentials and Cloud KMS configuration +Transit (Vault/OpenBao)::: Configure using `transitSecretRef` pointing to a secret containing connection details to another Vault/OpenBao instance + +Each secret reference should contain the necessary credentials and configuration for the respective provider. When auto-unseal is configured, OpenBao will automatically unseal after restarts without requiring the unseal keys from `writeUnsealKeysSecretToRef`. + +If no auto-unseal provider is configured, manual unsealing using the unseal keys is required after each pod restart. + +Example AWS KMS auto-unseal secret: + +```yaml +apiVersion: v1 +kind: Secret +metadata: + name: openbao-awskms-config +type: Opaque +stringData: + region: "us-east-1" + access_key: "AKIAIOSFODNN7EXAMPLE" + secret_key: "wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY" + kms_key_id: "19ec80b0-dfdd-4d97-8164-c6examplekey" + endpoint: "https://vpce-0e1bb1852241f8cc6-pzi0do8n.kms.us-east-1.vpce.amazonaws.com" +``` + +**Service Levels:** + +besteffort:: +- 1 or 3 instances +- Standard resource guarantees +- Best-effort availability + +guaranteed:: +- Requires 3 instances (HA deployment) +- Resource guarantees with pod anti-affinity +- Higher availability SLA + +TODO: Work on plan specifications + Key Components:: 1. **OpenBao Cluster**: 3-node HA deployment with Raft consensus From 0f159f31597c517c11265518e30446cfa3caa00c Mon Sep 17 00:00:00 2001 From: Yannik Daellenbach Date: Fri, 31 Oct 2025 17:09:09 +0100 Subject: [PATCH 07/12] Standardize ADR cross-references in OpenBao ADR --- docs/modules/ROOT/pages/adr/0049-managed-openbao.adoc | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/docs/modules/ROOT/pages/adr/0049-managed-openbao.adoc b/docs/modules/ROOT/pages/adr/0049-managed-openbao.adoc index 02f4ab0b..f09fba1a 100644 --- a/docs/modules/ROOT/pages/adr/0049-managed-openbao.adoc +++ b/docs/modules/ROOT/pages/adr/0049-managed-openbao.adoc @@ -13,12 +13,12 @@ include::partial$adr-meta.adoc[] .Summary ==== This ADR outlines the implementation of a managed OpenBao service on the AppCat platform to provide secret mananagement capabilities to customers. -This builds upon the suggestion of xref:adr/0024-product-choice-for-secret-management.adoc[ADR 0024] to use OpenBao as secret and PKI management solution. +This builds upon the suggestion of xref:adr/0024-product-choice-for-secret-management.adoc[] to use OpenBao as secret and PKI management solution. ==== == Context -Following the suggestion in ADR 0024 to use OpenBao for secret management, we need to implement it as a managed service within the AppCat ecosystem. OpenBao provides: +Following the suggestion in xref:adr/0024-product-choice-for-secret-management.adoc[] to use OpenBao for secret management, we need to implement it as a managed service within the AppCat ecosystem. OpenBao provides: - Secret storage with REST API - Vault API compatibility @@ -132,7 +132,7 @@ Storage Backend:: **API Specification:** -The VSHNOpenBao CRD follows AppCat conventions (ADR 0016) with parameter groups for service configuration, sizing, backup, monitoring, and maintenance. +The VSHNOpenBao CRD follows AppCat conventions (xref:adr/0016-service-api-design.adoc[]) with parameter groups for service configuration, sizing, backup, monitoring, and maintenance. ```yaml apiVersion: vshn.appcat.vshn.io/v1 From 1ddab2203bf81255dbd5758883b389ceb3806301 Mon Sep 17 00:00:00 2001 From: Yannik Daellenbach Date: Fri, 31 Oct 2025 17:13:44 +0100 Subject: [PATCH 08/12] Standardize secret reference and key names in OpenBao ADR --- .../ROOT/pages/adr/0049-managed-openbao.adoc | 17 ++++++++--------- 1 file changed, 8 insertions(+), 9 deletions(-) diff --git a/docs/modules/ROOT/pages/adr/0049-managed-openbao.adoc b/docs/modules/ROOT/pages/adr/0049-managed-openbao.adoc index f09fba1a..d7620d29 100644 --- a/docs/modules/ROOT/pages/adr/0049-managed-openbao.adoc +++ b/docs/modules/ROOT/pages/adr/0049-managed-openbao.adoc @@ -199,14 +199,13 @@ spec: # Unseal keys and root token secret reference # This secret will contain the unseal keys and root token generated during initialization - writeUnsealKeysSecretToRef: + writeConnectionSecretToRef: name: openbao-unseal-keys - namespace: "" # defaults to claim namespace ``` **Unseal Keys Secret:** -The `writeUnsealKeysSecretToRef` secret contains the unseal keys and root token: +The `writeConnectionSecretToRef` secret contains the unseal keys and root token: ```yaml apiVersion: v1 @@ -214,12 +213,12 @@ kind: Secret metadata: name: openbao-unseal-keys data: - unseal-key-1: - unseal-key-2: - unseal-key-3: - unseal-key-4: - unseal-key-5: - root-token: + UNSEAL_KEY_1: + UNSEAL_KEY_2: + UNSEAL_KEY_3: + UNSEAL_KEY_4: + UNSEAL_KEY_5: + ROOT_TOKEN: ``` **Auto unseal** From 2a3dc528564a5c02d511a534ae63a7a8d70e13f8 Mon Sep 17 00:00:00 2001 From: Yannik Daellenbach Date: Fri, 31 Oct 2025 17:14:56 +0100 Subject: [PATCH 09/12] Fix typo in OpenBao ADR summary --- docs/modules/ROOT/pages/adr/0049-managed-openbao.adoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/modules/ROOT/pages/adr/0049-managed-openbao.adoc b/docs/modules/ROOT/pages/adr/0049-managed-openbao.adoc index d7620d29..dc4d3cf3 100644 --- a/docs/modules/ROOT/pages/adr/0049-managed-openbao.adoc +++ b/docs/modules/ROOT/pages/adr/0049-managed-openbao.adoc @@ -12,7 +12,7 @@ include::partial$adr-meta.adoc[] [NOTE] .Summary ==== -This ADR outlines the implementation of a managed OpenBao service on the AppCat platform to provide secret mananagement capabilities to customers. +This ADR outlines the implementation of a managed OpenBao service on the AppCat platform to provide secret management capabilities to customers. This builds upon the suggestion of xref:adr/0024-product-choice-for-secret-management.adoc[] to use OpenBao as secret and PKI management solution. ==== From 33eb9e060861d2e00f6b278de68d7ab2d8d17213 Mon Sep 17 00:00:00 2001 From: Yannik Daellenbach Date: Fri, 31 Oct 2025 17:19:07 +0100 Subject: [PATCH 10/12] Update Proposal 2 title to specify Helm chart deployment --- docs/modules/ROOT/pages/adr/0049-managed-openbao.adoc | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/modules/ROOT/pages/adr/0049-managed-openbao.adoc b/docs/modules/ROOT/pages/adr/0049-managed-openbao.adoc index dc4d3cf3..4b32b22a 100644 --- a/docs/modules/ROOT/pages/adr/0049-managed-openbao.adoc +++ b/docs/modules/ROOT/pages/adr/0049-managed-openbao.adoc @@ -74,9 +74,9 @@ Disadvantages:: - Additional complexity in managing external dependencies - Potential performance overhead with external storage -=== Proposal 2: Integrated Deployment with Local Storage +=== Proposal 2: Helm Chart with Internal Storage -Deploy OpenBao with integrated storage using Raft consensus. +Deploy OpenBao using the official Helm chart with integrated storage using Raft consensus. Implementation:: From 0530eda76e42833ab9454de05e6176f7fc345345 Mon Sep 17 00:00:00 2001 From: Yannik Daellenbach Date: Tue, 16 Dec 2025 13:54:12 +0100 Subject: [PATCH 11/12] Clarify default auto-unseal behavior and add service level warning Adds documentation for the default VSHN-managed auto-unseal configuration and includes a warning that customer-configured auto-unseal providers only support besteffort service level. Also fixes typo in section heading. --- docs/modules/ROOT/pages/adr/0049-managed-openbao.adoc | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/docs/modules/ROOT/pages/adr/0049-managed-openbao.adoc b/docs/modules/ROOT/pages/adr/0049-managed-openbao.adoc index 4b32b22a..2c60ea13 100644 --- a/docs/modules/ROOT/pages/adr/0049-managed-openbao.adoc +++ b/docs/modules/ROOT/pages/adr/0049-managed-openbao.adoc @@ -221,10 +221,14 @@ data: ROOT_TOKEN: ``` -**Auto unseal** +**Auto-unseal** Auto unseal allows OpenBao to unseal automatically without manual intervention using an external key management system. This is crucial for automated recovery and reduces operational burden. +By default OpenBao instances will be configured to use a central, internal VSHN managed Vault or OpenBao to auto-unseal. + +WARNING: If a customer configures an auto-unseal provider, only the service level "besteffort" can be guaranteed. + Supported auto-unseal providers: AWS KMS::: Configure using `awsKmsSecretRef` pointing to a secret containing AWS credentials and KMS key configuration @@ -314,4 +318,4 @@ Customer Benefits:: - Self-hosted alternative to cloud secret management services - Vault API compatibility for existing applications and tooling -- Compliance with data sovereignty requirements \ No newline at end of file +- Compliance with data sovereignty requirements From 97a153017d42793754f5ccffc6bdd810784da361 Mon Sep 17 00:00:00 2001 From: Yannik Daellenbach Date: Tue, 16 Dec 2025 14:08:25 +0100 Subject: [PATCH 12/12] Add plan specifications to OpenBao ADR --- .../modules/ROOT/pages/adr/0049-managed-openbao.adoc | 12 +++++++++++- 1 file changed, 11 insertions(+), 1 deletion(-) diff --git a/docs/modules/ROOT/pages/adr/0049-managed-openbao.adoc b/docs/modules/ROOT/pages/adr/0049-managed-openbao.adoc index 2c60ea13..cbdd3e60 100644 --- a/docs/modules/ROOT/pages/adr/0049-managed-openbao.adoc +++ b/docs/modules/ROOT/pages/adr/0049-managed-openbao.adoc @@ -268,7 +268,17 @@ guaranteed:: - Resource guarantees with pod anti-affinity - Higher availability SLA -TODO: Work on plan specifications +**Plans:** + +By default, the following plans are available on every cluster: + +[cols="25a,15,15,15", options="header"] +|=== +| Plan | CPU | Memory | Disk +| standard-2 | 500m | 2Gi | 16Gi +| standard-4 | 1 | 4Gi | 16Gi +| standard-8 | 2 | 8Gi | 16Gi +|=== Key Components::