Self-hosted secrets management for SaaS companies

The auditor expects a documented policy that states where secrets may live, who owns each secret class, how often static credentials rotate, and what happens when a secret is suspected to be exposed. The policy should match what the platform actually enforces. In a self-hosted OpenBao or Infisical deployment, the policy is usually backed by path layout, lease durations for dynamic credentials and rotation settings. Auditors compare the written policy with configuration exports and sample records, so gaps between the document and the system tend to surface as findings. DeployOpen can help draft the policy against the security common criteria and document the configuration that proves it. The policy itself, and the judgment that it is adequate, remain the organization's responsibility and the auditor's to test.

Auditors look for a recurring review in which named owners confirm that each policy, role and auth binding still matches current team membership and need. For secrets tooling, the evidence is an exported list of policies, roles, AppRoles, Kubernetes auth bindings and CI JWT roles, with the reviewer, date and the decisions recorded. Removed engineers and decommissioned pipelines should show up as closed items in the review. The review cadence is set by the organization's own policy, and the auditor tests whether it happened as described. The review tool is usually a ticket or GRC workflow, with the secrets platform supplying the data. Confirm with your auditor which review period they will sample.

Auditors ask for records showing who or what read or changed each secret, when, and from where, and they ask how those records are protected and reviewed. In OpenBao, the audit devices write request and response entries, which should be sent to a log store outside the cluster so that operators cannot quietly alter them. The evidence set typically includes a sample of reads traced back to a named identity such as a Kubernetes service account, a CI job or a human user, plus proof that the log pipeline was running over the audit period. Log retention and the review process belong in your policy. Confirm with your auditor which log fields and retention length they expect, and whether they want the SIEM export tested as part of the sample.

The evidence is a configuration record showing how encryption at rest is set up, plus proof that the stored data is not readable without the unseal material. For OpenBao, encryption happens before data is written to the storage backend, whether integrated Raft storage or PostgreSQL. Auditors typically ask for the storage configuration, the seal configuration, a description of where the unseal or recovery material is held, and a sample showing that the backend contents are ciphertext. If the database or disk underneath is also encrypted, that layer should be documented separately. For Kubernetes-hosted workloads, the native Secrets in etcd are stored unencrypted by default, so the encryption configuration of etcd and the Secrets Store integration should also appear in the evidence.

A restore test record shows that a backup was taken, that it was restored into a separate environment, and that the restored platform served the expected secrets and audit trail. Auditors look for the date, the operator, the backup identifier, the target environment, the outcome and any defects raised. For a self-hosted OpenBao cluster, the test should also cover the recovery keys and the unseal procedure, because a backup without the matching key material is not recoverable. Kubernetes etcd guidance recommends a backup plan and uses snapshot tooling, so the record for an etcd-backed cluster should reference that process too. Ask the auditor how many tests they expect in the period and whether restores into a non-production environment satisfy them.

Auditors expect change records for every event that touches the root of trust, including initialization, unseal key distribution, rekeying, root token generation and revocation, and seal or storage migrations. Each record should name the approvers, the participants who held key shares, the date, the ticket and the verification step. The records should show dual control or split knowledge where the policy requires it. Keys held in escrow or a password vault should have their own custody log. These records usually live in the change management system rather than in the secrets platform, so they must be linked to the platform's audit events. DeployOpen can help define the procedure and the record template. Custody decisions are the organization's to make and must be approved by its own governance.

No. DeployOpen prepares systems, controls and evidence for a compliance assessment, but it does not issue SOC 2 reports, attestations or certifications. The AICPA sets the 2017 Trust Services Criteria used in SOC 2 examinations, and an independent CPA firm performs the examination and issues the report, either as a Type 1 report on design as of a date or as a Type 2 report that also covers operating effectiveness over a period. DeployOpen's role is to configure the secrets platform, document how each control operates, collect the evidence described above and hand it to your team and your auditor. Ask your audit firm which evidence format and sample periods they will accept before work starts.

Yes, many engineering and security teams can produce this evidence in-house if they have the time, documented procedures and someone who owns each control. The main effort is not the export of logs or configuration, but keeping records current across the audit period, which is where many findings originate. A partner's value is usually in designing the control set, building repeatable evidence collection and running restore tests on a schedule. Whether to build internally or engage a partner depends on your team's capacity and the size of the audit scope. The engagement scope should be written down before work starts, so you know which records DeployOpen produces and which your team retains.

The cost splits into infrastructure, integration work, operations time and the partner scope, if you use one. Infrastructure covers the OpenBao nodes, the storage backend, backups, load balancing and the environments you run for staging and production. Integration work covers each CI pipeline, Kubernetes workload and service that moves from static credentials to OpenBao. Operations time covers upgrades, monitoring, unseal procedures and on-call. OpenBao itself is MPL-2.0 licensed, so there is no per-secret or per-call license fee in the open-source edition, but you should confirm the feature set you need against the current OpenBao documentation. Ask any partner for a quote that lists each component separately, with who pays for each one.

One-time costs include the initial design, the migration of secrets from code, configuration files and CI variables, the first integration of each pipeline and service, and the setup of high availability and backup testing. Recurring costs include compute and storage for the cluster, backup retention, upgrades to new OpenBao minor and patch releases, on-call coverage, periodic rotation reviews, audit log storage and any support retainer. A common planning mistake is treating the migration as a one-off when new services keep arriving, so budget a recurring share for onboarding each new workload. Ask a quote to separate these two groups so you can compare the first year with later years.

Integration effort scales with the number of distinct consumers and how different they are. Each GitLab or other pipeline that switches to JWT/OIDC login needs its own policy scoped to the project. Each Kubernetes namespace or workload needs an auth role, and you choose between injector, CSI or direct API patterns. Dynamic database credentials add work per database engine and per application connection pool. Legacy services with hard-coded credentials usually cost the most because they need code changes and a rollout window. Ask the partner to inventory consumers by type, count the ones that need code changes, and price those separately from configuration-only changes.

The time to a first pilot depends on the state of the environment, the team's familiarity with Kubernetes and OpenBao, and how many consumers the pilot includes. A pilot usually needs an agreed architecture, a non-production cluster, one or two auth methods and a single low-risk workload or pipeline. Delays most often come from waiting for network paths, identity provider configuration, change approvals and the availability of the internal owners who must sign off on policies. No duration is stated here because none has been supplied for this scope. Ask any partner for a written timeline with dated milestones and named dependencies on your side.

The internal team provides decisions and access rather than most of the build work. You need a named owner for secret policies, engineers who understand each pipeline and service, access to Kubernetes clusters and CI systems, a process for approving changes to production, and staff who can hold unseal and recovery material under your key custody rules. Platform engineers should also be ready to take over runbooks for upgrades and backups. Confirm these roles early, because the most common slowdown is a service owner who is not available to test a changed credential path.

A small team can run OpenBao alone if it has someone comfortable with Kubernetes or Linux operations, a tested backup and restore procedure, documented unseal steps and monitoring for the cluster. The harder parts are high availability design, upgrades that keep the cluster healthy, and incident response when a node fails during business hours. Many teams start with a partner for the design, migration and runbooks, then take over operations. Whether your team can carry this alone depends on your on-call capacity and on how many services will depend on the cluster, so assess that before you commit.

DeployOpen does not publish a price list. Most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts, and a quote follows from that written scope. To request one, prepare an inventory of pipelines, Kubernetes clusters, databases and services that will consume secrets, the current secret storage locations, the target environments, and any requirements for HSM, air-gapped operation or audit log delivery. Ask for the quote to list the one-time work, the recurring support options and the assumptions about your environment. Ongoing support, upgrades and continuous testing are available as retainers, and they can be quoted separately.