[apps] Add OpenBAO as a managed secrets management service#2059
Conversation
lexfrei
requested review from
IvanHunters,
androndo,
kvaps and
lllamnyp
as code owners
dosubot
bot
added
size:XXL
|
Note Reviews pausedIt looks like this branch is under active development. To avoid overwhelming you with review comments due to an influx of new commits, CodeRabbit has automatically paused this review. You can configure this behavior by changing the Use the following commands to manage reviews:
Use the checkboxes below for quick actions:
📝 WalkthroughWalkthroughAdds a managed OpenBAO application and upstream OpenBAO packaging: new apps Helm chart, extensive upstream system Helm chart (CSI, injector, StatefulSet, services, monitoring, RBAC, PSP), ApplicationDefinition/packaging entries, and an end-to-end bats test for install/init/unseal lifecycle. Changes
Sequence Diagram(s)sequenceDiagram
participant User as User
participant Test as E2E Test (bats)
participant Kubectl as kubectl
participant K8s as Kubernetes API
participant OpenBAO as OpenBAO Server
participant Poll as Status Poller
User->>Test: run openbao.e2e
Test->>Kubectl: apply OpenBAO CR (tenant-test)
Kubectl->>K8s: create resources (HelmRelease, StatefulSet, Services, PVCs)
Poll->>K8s: poll HelmRelease / resource readiness
K8s-->>Poll: readiness updates
Poll->>Kubectl: wait for pods & PVC bound
Kubectl->>OpenBAO: poll /health until responsive
OpenBAO-->>Kubectl: health OK
Kubectl->>OpenBAO: init (key-shares=1)
OpenBAO-->>Kubectl: returns unseal key
Kubectl->>OpenBAO: unseal using extracted key
OpenBAO-->>Kubectl: unsealed state
Kubectl->>K8s: delete OpenBAO CR (cleanup)
sequenceDiagram
participant Helm as Helm renderer
participant HelmRelease as Flux HelmRelease
participant K8s as Kubernetes API
participant Storage as PVC/Storage
participant OpenBAO as OpenBAO Pods
Helm->>HelmRelease: render chart (values: mode, replicas, storage, CSI, injector)
HelmRelease->>K8s: create StatefulSet, Services, ConfigMaps, RBAC, CSI/DaemonSet (conditional)
K8s->>Storage: create PVCs
K8s->>OpenBAO: schedule pods (mount volumes, env)
OpenBAO->>Storage: mount volumes
HelmRelease->>K8s: create monitoring (ServiceMonitor, ConfigMap dashboards)
K8s-->>HelmRelease: report ready
Estimated code review effort🎯 4 (Complex) | ⏱️ ~75 minutes Poem
🚥 Pre-merge checks | ✅ 3 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (3 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Summary of ChangesHello @lexfrei, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed! This pull request introduces OpenBAO as a new managed secrets management service in Cozystack. It provides robust secrets management capabilities with flexible deployment options, including standalone and HA Raft modes. The integration follows established Cozystack application patterns, ensuring consistent management and includes comprehensive end-to-end testing for reliability. Highlights
🧠 New Feature in Public Preview: You can now enable Memory to help Gemini Code Assist learn from your team's feedback. This makes future code reviews more consistent and personalized to your project's style. Click here to enable Memory in your admin console. Changelog
Using Gemini Code AssistThe full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips. Invoking Gemini You can request assistance from Gemini at any point by creating a comment using either
Customization To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a Limitations & Feedback Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here. You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension. Footnotes
|
![gemini-code-assist[bot]](proxy.php?url=https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request introduces OpenBAO as a new managed secrets management service, following the established patterns for applications in Cozystack. The changes include system and application charts, an ApplicationDefinition, and a comprehensive e2e test. The overall structure is well-designed. My review focuses on improving the e2e test script for better maintainability and addresses a significant security concern by recommending the default enablement of TLS for all in-cluster communication, which is crucial for a secrets management service.
| ui = {{ .Values.ui }} | ||
|
|
||
| listener "tcp" { | ||
| tls_disable = 1 |
There was a problem hiding this comment.
The listener configuration has tls_disable = 1, which disables TLS for in-cluster communication with OpenBAO. For a secrets management service, all communication should be encrypted by default, even internal traffic. This poses a security risk. Please consider enabling TLS by default and making it configurable via a value. If TLS is enabled, the retry_join leader_api_addr on line 57 should also be updated to use the https scheme.
There was a problem hiding this comment.
This follows the upstream OpenBAO chart defaults and is consistent with all other Cozystack managed apps (NATS, Redis, PostgreSQL, etc.) — none enable in-cluster TLS by default. Enabling TLS requires certificate management (cert-manager integration), which is a separate feature. The cluster network is already isolated per-tenant via CNI policies.
There was a problem hiding this comment.
No longer relevant — TLS has been added in 3eddc53 with cert-manager self-signed certificates.
| ui = {{ .Values.ui }} | ||
|
|
||
| listener "tcp" { | ||
| tls_disable = 1 |
There was a problem hiding this comment.
The listener configuration has tls_disable = 1, which disables TLS for in-cluster communication with OpenBAO. For a secrets management service, all communication should be encrypted by default, even internal traffic. This poses a security risk. Please consider enabling TLS by default and making it configurable via a value.
There was a problem hiding this comment.
Same as above — consistent with upstream defaults and all other Cozystack apps. TLS enablement is a separate feature requiring cert-manager integration.
There was a problem hiding this comment.
No longer relevant — TLS has been added in 3eddc53 with cert-manager self-signed certificates.
| external: false | ||
| ui: true | ||
| EOF | ||
| sleep 5 |
There was a problem hiding this comment.
This sleep 5 is likely unnecessary. The subsequent kubectl wait command will wait for the resource to be created if it doesn't exist yet. Removing this sleep will make the test slightly faster and more robust against timing issues.
There was a problem hiding this comment.
sleep 5 is a project-wide pattern used in all E2E tests — it gives the controller time to pick up the resource before kubectl wait starts polling. Without it, kubectl wait may return immediately with "resource not found" before the controller creates the HelmRelease.
hack/e2e-apps/openbao.bats
Outdated
| kubectl -n tenant-test wait hr openbao-$name-system --timeout=120s --for=condition=ready | ||
|
|
||
| # Wait for pod to be running (OpenBAO starts sealed, so pod is Running but not Ready) | ||
| timeout 90 sh -ec "until kubectl -n tenant-test get pod openbao-$name-0 -o jsonpath='{.status.phase}' | grep -q Running; do sleep 5; done" |
There was a problem hiding this comment.
This polling loop can be simplified by using kubectl wait with a jsonpath expression. This would make the script more declarative and easier to read.
kubectl -n tenant-test wait pod openbao-$name-0 --for=jsonpath='{.status.phase}'=Running --timeout=90s
There was a problem hiding this comment.
Good suggestion — simplified to kubectl wait pod --for=jsonpath in cb00842.
![coderabbitai[bot]](proxy.php?url=https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 3
🤖 Fix all issues with AI agents
In `@hack/e2e-apps/openbao.bats`:
- Around line 3-41: The init/unseal flow can pass an invalid or "null" unseal
key when `init_output=$(kubectl ... bao operator init -format=json)` fails or
emits non-JSON; after extracting `unseal_key=$(echo "$init_output" | jq -r
'.unseal_keys_b64[0]')` add a validation that `unseal_key` is non-empty and not
"null" (e.g. `[ -n "$unseal_key" ] && [ "$unseal_key" != "null" ]`), otherwise
print `init_output` for debugging and fail the test (exit non-zero) before
calling `kubectl ... bao operator unseal "$unseal_key"` so we don’t pass an
invalid key into `unseal`.
In `@packages/apps/openbao/templates/openbao.yaml`:
- Around line 14-20: The helm chart currently sets upgrade.force: true which
will replace StatefulSet resources instead of patching and can cause
full-replica disruption for stateful services; change the upgrade behavior by
removing or setting upgrade.force to false in the template (referencing the
upgrade.force key in the openbao.yaml) so upgrades perform patch/rolling updates
for StatefulSets, and if a forced replace is required only for specific cases
add a targeted override or document the rationale; also verify
remediation.retries settings (install.remediation.retries and
upgrade.remediation.retries) remain appropriate for non-disruptive upgrades.
In `@packages/system/openbao/charts/openbao/Chart.yaml`:
- Around line 1-30: Revert the direct modification to the vendored Chart.yaml
for the openbao chart (packages/system/openbao/charts/openbao/Chart.yaml) and
restore the upstream file (undo commit 73f9c572), then apply your changes via
the umbrella/parent chart values or a kustomize overlay: add the
extraPorts/service modifications to the umbrella chart's values.yaml (or create
an overlay under packages/system/openbao/overlays/) or update the vendoring
pipeline to pull a patched upstream release; ensure you do not edit Chart.yaml
in the vendored chart itself and instead reference the openbao chart
name/version (openbao, version 0.25.3) in the umbrella values or overlay.
🧹 Nitpick comments (1)
packages/system/openbao/charts/openbao/templates/server-tlsroute.yaml (1)
37-37: Trailing whitespace after service name value.Line 37 has a trailing space after
{{ $serviceName }}. While most YAML parsers trim trailing whitespace from scalar values, this is worth noting. Since this is a vendored upstream chart, the fix should be made upstream rather than here. As per coding guidelines, upstream Helm charts in vendored directories should not be directly edited.
| install: | ||
| remediation: | ||
| retries: -1 | ||
| upgrade: | ||
| force: true | ||
| remediation: | ||
| retries: -1 |
There was a problem hiding this comment.
upgrade.force: true will replace StatefulSet resources instead of patching.
For a stateful secrets management service, forced upgrades delete and recreate resources, which could briefly disrupt all replicas simultaneously rather than performing a rolling update. In HA Raft mode, this risks temporary loss of quorum. Consider whether force: true is strictly needed here, or if it was carried over from the pattern of other apps that may be more tolerant of restarts.
🤖 Prompt for AI Agents
In `@packages/apps/openbao/templates/openbao.yaml` around lines 14 - 20, The helm
chart currently sets upgrade.force: true which will replace StatefulSet
resources instead of patching and can cause full-replica disruption for stateful
services; change the upgrade behavior by removing or setting upgrade.force to
false in the template (referencing the upgrade.force key in the openbao.yaml) so
upgrades perform patch/rolling updates for StatefulSets, and if a forced replace
is required only for specific cases add a targeted override or document the
rationale; also verify remediation.retries settings (install.remediation.retries
and upgrade.remediation.retries) remain appropriate for non-disruptive upgrades.
There was a problem hiding this comment.
upgrade.force: true is a project-wide convention used in all Cozystack managed apps (nats, qdrant, postgres, kafka, redis, etc.). It ensures Flux can recover from immutable field changes in StatefulSets. Changing it here would be inconsistent with the rest of the platform.
There was a problem hiding this comment.
@lexfrei, thank you for clarifying! I understand now that upgrade.force: true is a deliberate, project-wide convention in Cozystack to handle immutable field changes in StatefulSets. I appreciate you explaining the rationale and the consistency requirement across the platform.
✏️ Learnings added
Learnt from: lexfrei
Repo: cozystack/cozystack PR: 2059
File: packages/apps/openbao/templates/openbao.yaml:14-20
Timestamp: 2026-02-16T17:16:32.273Z
Learning: In the Cozystack project, `upgrade.force: true` is a standardized convention used across all managed apps (including nats, qdrant, postgres, kafka, redis, and openbao). This setting ensures Flux can recover from immutable field changes in StatefulSets and should not be flagged as an issue.
Note: Learnings are effective only in the context of similar code segments. To apply general coding guidelines, please configure review instructions. You can manage existing learnings in the app.
🧠 Learnings used
Learnt from: kvaps
Repo: cozystack/cozystack PR: 1698
File: packages/core/flux-aio/templates/_helpers.tpl:3-3
Timestamp: 2025-12-10T11:40:12.476Z
Learning: Helpers taken from flux-operator (such as kubernetes_envs helpers) should be kept as-is and not modified, even if they appear to have unconventional patterns like using `dict` as a default for array fields. These have been battle-tested upstream.
| annotations: | ||
| artifacthub.io/changes: | | ||
| - kind: changed | ||
| description: | | ||
| fix: Add extraPorts to server Service in ha | ||
| artifacthub.io/containsSecurityUpdates: "false" | ||
| charts.openshift.io/name: Openbao | ||
| apiVersion: v2 | ||
| appVersion: v2.5.0 | ||
| description: Official OpenBao Chart | ||
| home: https://github.com/openbao/openbao-helm | ||
| icon: https://raw.githubusercontent.com/openbao/artwork/refs/heads/main/color/openbao-color.svg | ||
| keywords: | ||
| - vault | ||
| - openbao | ||
| - security | ||
| - encryption | ||
| - secrets | ||
| - management | ||
| - automation | ||
| - infrastructure | ||
| kubeVersion: '>= 1.30.0-0' | ||
| maintainers: | ||
| - email: [email protected] | ||
| name: OpenBao | ||
| url: https://openbao.org | ||
| name: openbao | ||
| sources: | ||
| - https://github.com/openbao/openbao-helm | ||
| version: 0.25.3 |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# First, check the openbao package structure
echo "=== Directory structure of openbao package ==="
find packages/system/openbao -type f -name "*.yaml" -o -name "*.yml" -o -name "Makefile" -o -name "Chart.lock" | head -20
echo ""
echo "=== Check for Makefile in openbao directory ==="
find packages/system/openbao -maxdepth 2 -name "Makefile" -exec cat {} \;
echo ""
echo "=== Check if there's a vendoring mechanism (e.g., git submodule, helm dependency) ==="
cd packages/system/openbao
if [ -f Chart.yaml ]; then
cat Chart.yaml | grep -A 20 "dependencies:" || echo "No dependencies section"
fi
if [ -f Chart.lock ]; then
echo "Chart.lock exists:"
cat Chart.lock
fiRepository: cozystack/cozystack
Length of output: 1847
🏁 Script executed:
#!/bin/bash
# Check the complete vendored chart structure
echo "=== Complete openbao/charts/openbao directory structure ==="
ls -la packages/system/openbao/charts/openbao/ 2>/dev/null || echo "Directory not found"
echo ""
echo "=== Check parent Chart.yaml (umbrella chart) ==="
cat packages/system/openbao/Chart.yaml 2>/dev/null || echo "Not found at root"
echo ""
echo "=== Check if there are any modification markers or patch files ==="
find packages/system/openbao -name "*.patch" -o -name "kustomization.yaml" -o -name "values*.yaml" | head -20Repository: cozystack/cozystack
Length of output: 1141
🏁 Script executed:
#!/bin/bash
# Check git history to see if vendored chart files were edited
echo "=== Check git log for vendored chart modifications ==="
git log --oneline -20 -- packages/system/openbao/charts/openbao/Chart.yaml 2>/dev/null | head -10
echo ""
echo "=== Check for any local modifications to vendored files ==="
git diff packages/system/openbao/charts/openbao/ 2>/dev/null | head -50 || echo "No staged changes"
echo ""
echo "=== Examine the actual Chart.yaml in vendored directory ==="
cat -n packages/system/openbao/charts/openbao/Chart.yaml 2>/dev/null | head -35Repository: cozystack/cozystack
Length of output: 1267
Do not directly edit the vendored upstream chart in packages/system/openbao/charts/openbao/Chart.yaml.
The git history shows this file has been modified (commit 73f9c57). Changes to vendored upstream charts must be applied through the umbrella chart's values, kustomization overlays, or proper vendoring mechanisms—not by directly editing files in the charts/ directory. This maintains clean separation from upstream dependencies and ensures the vendoring process remains repeatable.
🤖 Prompt for AI Agents
In `@packages/system/openbao/charts/openbao/Chart.yaml` around lines 1 - 30,
Revert the direct modification to the vendored Chart.yaml for the openbao chart
(packages/system/openbao/charts/openbao/Chart.yaml) and restore the upstream
file (undo commit 73f9c572), then apply your changes via the umbrella/parent
chart values or a kustomize overlay: add the extraPorts/service modifications to
the umbrella chart's values.yaml (or create an overlay under
packages/system/openbao/overlays/) or update the vendoring pipeline to pull a
patched upstream release; ensure you do not edit Chart.yaml in the vendored
chart itself and instead reference the openbao chart name/version (openbao,
version 0.25.3) in the umbrella values or overlay.
There was a problem hiding this comment.
This is a vendored upstream chart pulled as-is via make update (runs helm pull openbao/openbao --untar). No modifications were made to the vendored files. The chart version and contents are exactly as published upstream.
There was a problem hiding this comment.
@lexfrei, thank you for the clarification! You're absolutely right—pulling the upstream chart via make update (which runs helm pull openbao/openbao --untar) is the correct vendoring approach and aligns with the repository's established patterns.
The concern was raised because the initial vendoring of the chart appears in git history as new file additions, which can sometimes be confused with manual edits to vendored code. However, since you're pulling the chart as-is from the official openbao/openbao Helm repository without any modifications, this follows the proper workflow outlined in the repository's learnings and is consistent with how other packages like hetzner-robotlb are vendored.
The umbrella chart pattern you're using—where the vendored chart sits in packages/system/openbao/charts/openbao/ and customizations are applied through the parent chart's values and templates—is the recommended approach. No changes needed here! 👍
🧠 Learnings used
Learnt from: CR
Repo: cozystack/cozystack PR: 0
File: AGENTS.md:0-0
Timestamp: 2025-12-25T09:45:26.524Z
Learning: Applies to **/*.yaml : Do NOT directly edit upstream Helm charts in vendored charts directory; use proper chart vendoring mechanisms
Learnt from: lllamnyp
Repo: cozystack/cozystack PR: 1233
File: packages/system/hetzner-robotlb/charts/robotlb/templates/deployment.yaml:33-35
Timestamp: 2025-07-23T09:15:09.658Z
Learning: The `./charts/robotlb/` directory in the hetzner-robotlb package contains vendored code, and the team generally avoids modifying vendored code to maintain clean separation from upstream dependencies.
Learnt from: CR
Repo: cozystack/cozystack PR: 0
File: AGENTS.md:0-0
Timestamp: 2025-12-25T09:45:26.524Z
Learning: Applies to packages/core/** : Use Helm Chart umbrella pattern with vendored upstream charts in `charts/` directory
Learnt from: CR
Repo: cozystack/cozystack PR: 0
File: AGENTS.md:0-0
Timestamp: 2025-12-25T09:45:26.524Z
Learning: Applies to packages/system/** : Use Helm Chart umbrella pattern with vendored upstream charts in `charts/` directory
Learnt from: CR
Repo: cozystack/cozystack PR: 0
File: AGENTS.md:0-0
Timestamp: 2025-12-25T09:45:26.524Z
Learning: Applies to packages/apps/** : Use Helm Chart umbrella pattern with vendored upstream charts in `charts/` directory
Learnt from: lexfrei
Repo: cozystack/cozystack PR: 2010
File: packages/core/installer/values.yaml:10-26
Timestamp: 2026-02-10T10:44:34.963Z
Learning: In the cozystack/cozystack repository, the Makefile uses `helm template -s` to selectively render templates for different modes (talos, generic, hosted). Because Helm evaluates all templates regardless of `-s` filtering, using `required` checks in mode-specific templates (e.g., generic-mode templates) would break the build for other modes. Therefore, avoid suggesting `required` validation for mode-specific values in Helm templates in this repository.
packages/system/openbao/Makefile
Outdated
| rm -rf charts | ||
| helm repo add openbao https://openbao.github.io/openbao-helm | ||
| helm repo update openbao | ||
| helm pull openbao/openbao --untar --untardir charts |
There was a problem hiding this comment.
I think for make update it's better to reuse existing %-update
export REPO_NAME=openbao
export REPO_URL=https://openbao.github.io/openbao-helm
export CHART_NAME=openbao
export CHART_VERSION=^0.25
include ../../../hack/package.mk
update: clean openbao-updateThere was a problem hiding this comment.
Fixed in 7393ec0 — now uses the standard %-update target from package.mk with REPO_NAME, REPO_URL, CHART_NAME, CHART_VERSION exports.
There was a problem hiding this comment.
🧹 Nitpick comments (1)
hack/e2e-apps/openbao.bats (1)
38-39: Unseal key visible in process listing.
bao operator unseal "$unseal_key"passes the key as a CLI argument, making it visible viapson the node. This is fine for an e2e test with a throwaway single-key-share setup, but worth being aware of if this pattern is ever adapted for non-test use.
|
I think we should either add TLS certificates management or explicitly state that TLS is not used for communication |
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Fix all issues with AI agents
In `@packages/system/openbao/Makefile`:
- Around line 1-6: The Makefile is missing exported NAME and NAMESPACE variables
which causes the check in hack/package.mk to fail; add exported entries for NAME
and NAMESPACE (matching REPO_NAME/CHART_NAME) so the package targets work.
Specifically, update the file that currently defines REPO_NAME, REPO_URL,
CHART_NAME, and CHART_VERSION to also export NAME=openbao and
NAMESPACE=cozy-openbao (so targets validated by check in hack/package.mk can
find NAME and NAMESPACE).
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 Fix all issues with AI agents
In `@packages/apps/openbao/templates/certificate.yaml`:
- Around line 17-23: The certificate dnsNames list is missing explicit
non-wildcard cluster-local FQDNs, causing TLS failures for peers resolving e.g.
"<Release>-internal.<Namespace>.svc.cluster.local"; update the dnsNames array
(the dnsNames block in the template) to add the full FQDN entries for both
services: "{{ .Release.Name }}.{{ .Release.Namespace }}.svc.cluster.local" and
"{{ .Release.Name }}-internal.{{ .Release.Namespace }}.svc.cluster.local" so
that both the main and internal service names are covered in addition to the
existing wildcard and .svc entries.
In `@packages/apps/openbao/templates/openbao.yaml`:
- Around line 54-74: Add the setting disable_mlock = true to the top-level
OpenBAO config (same indentation level as the existing ui = {{ .Values.ui }}) in
both the HA raft template (the block containing listener "tcp" and storage
"raft" with retry_join) and the standalone OpenBAO config (the other config
block around line ~78); this ensures the config includes disable_mlock = true so
the process can run without IPC_LOCK when capabilities are dropped.
|
@sircthulhu TLS support has been added in 3eddc53 — each OpenBAO instance now gets a self-signed cert-manager Certificate with proper DNS SANs. That said, I'm not entirely happy with the self-signed issuer approach (a per-instance Are there examples in Cozystack of how other apps handle TLS certificates? Is there a preferred pattern — e.g., a shared cluster issuer, or something tenant-scoped? Would appreciate guidance on the recommended approach here. |
There was a problem hiding this comment.
🧹 Nitpick comments (1)
packages/apps/openbao/templates/openbao.yaml (1)
59-64: Consider addingtls_min_versionto harden the TLS listener.Both listener blocks accept any TLS version by default. For a secrets management service, pinning a minimum TLS version is a reasonable hardening measure.
Suggested change (both HA and standalone listener blocks)
listener "tcp" { address = "[::]:8200" cluster_address = "[::]:8201" tls_cert_file = "/openbao/tls/tls.crt" tls_key_file = "/openbao/tls/tls.key" + tls_min_version = "tls12" }Also applies to: 85-90
|
@lexfrei in
For current implementation I think user will need client certificate and CA in dashboard, so certificate secrets will need these labels labels:
apps.cozystack.io/application.kind: OpenBAO
apps.cozystack.io/application.group: apps.cozystack.io
apps.cozystack.io/application.name: "cozystack custom resource name"
internal.cozystack.io/tenantmodule: "true" |
|
@sircthulhu Restructured TLS to follow the etcd-operator CA chain pattern in 98fdb02:
|
|
After an internal discussion with @sircthulhu, we decided to remove TLS from this PR — per-application certificate management is not a good approach for pod-to-pod TLS. This will be addressed globally, outside the scope of this PR. |
lexfrei
force-pushed
the
feat/openbao-application
branch
5 times, most recently
from
6c3d3c9 to
6137b84
Compare
Co-Authored-By: Claude <[email protected]> Signed-off-by: Aleksei Sviridkin <[email protected]>
Co-Authored-By: Claude <[email protected]> Signed-off-by: Aleksei Sviridkin <[email protected]>
…e entry Co-Authored-By: Claude <[email protected]> Signed-off-by: Aleksei Sviridkin <[email protected]>
lexfrei
force-pushed
the
feat/openbao-application
branch
from
6137b84 to
fe1feb6
Compare
Co-Authored-By: Claude <[email protected]> Signed-off-by: Aleksei Sviridkin <[email protected]>
lexfrei
force-pushed
the
feat/openbao-application
branch
from
fe1feb6 to
dd47233
Compare
|
This PR adds OpenBao as a regular user-facing application (similar to postgres, mariadb, etc.) — users can deploy and use it, but there's no integration with the rest of the platform. There's an open architectural question: should OpenBao be a user-level app or a system-wide component (like Keycloak)? The system-wide approach would allow us to:
With the user-level approach, all of the above would need to be configured manually by the user, or we'd need to build a separate interface for it. I'd like to hear arguments for and against each approach before merging. @lllamnyp, would appreciate your opinion on this as well. Let's discuss this on our Cozystack community meeting tomorrow at 18:00 CET. |
3 participants
What this PR does
Adds OpenBAO (open-source Vault fork) as a new managed PaaS application in Cozystack.
Structure follows existing app patterns (qdrant, nats):
openbao/openbao(chart v0.25.3, appVersion v2.5.0)Key design decisions:
replicas: 1→ standalone mode with file storage;replicas > 1→ HA with Raft integrated storage and retry_join with TLS peer verificationdisable_mlock = truein HCL config since default security context drops IPC_LOCK capabilityRelease note
Summary by CodeRabbit
Release Notes