Why CI/CD secrets management needs its own design
Consider a regulated engineering team whose GitLab CI/CD variables hold long-lived cloud access keys and database passwords, copied across dozens of projects and rarely rotated. The fix is to replace those static pipeline secrets with short-lived credentials issued per job by a self-hosted OpenBao, which logs in with the job's identity and receives only what that job needs. Pipeline secrets are a different problem from workforce passwords or application secrets, because the caller is a non-human identity that runs code on demand, often with deploy rights to production. A compromised runner or a leaked variable can give an attacker the same reach as an engineer with administrator access, and nobody is standing at a keyboard to notice the difference.
That is why the design has to start with the identity of the job rather than the secret itself. Each pipeline needs a trust relationship with the secrets manager, such as a JWT or OIDC login that binds a token to the project, branch and runner, and policies that scope each role to one project's paths. The self-hosted candidates are OpenBao, licensed under MPL-2.0, and Infisical, which is MIT-licensed except for content in ee directories under a separate enterprise license. HashiCorp Vault from version 1.15.0 onward is licensed under the Business Source License 1.1, which is not an OSI-approved open source license, so teams that want to avoid that constraint should confirm the license terms before selecting it. Confirm the license obligations for each candidate with counsel before committing.
The runners themselves also shape the design. GitLab Runners and other CI systems may run on infrastructure the client controls, in which case the secrets manager can sit on the same network and the runner's trust boundary becomes part of the threat model. Decide early whether runners are shared across projects or dedicated to sensitive ones, because that choice determines which jobs can present which identities. Ask the implementation partner how runner identity is verified, who can change pipeline definitions that request secrets, and how the audit trail will show which job read which secret.
What the regulations and controls require from pipeline credentials
This table maps two US requirements to the parts of a CI/CD secrets design that an assessor will examine. Read each row as a question the pipeline must answer with evidence, not as a legal conclusion. The main takeaway is that a pipeline job is not a person, so each job needs its own identity, every secret read needs a record, and humans who change pipelines need MFA.
| Requirement | What it asks for in the pipeline | Evidence an assessor will expect |
|---|---|---|
| Unique user identification (HIPAA 45 CFR 164.312) | Each job, runner and project gets its own identity instead of a shared CI service account or a copied token | Mapping of each pipeline identity to a project and job type, with no shared credentials in use |
| Person or entity authentication (HIPAA 45 CFR 164.312) | Jobs prove who they are with a short-lived token from the CI platform, such as a JWT or OIDC claim, before OpenBao issues anything | Auth method configuration and sample logs showing the verified claims for each login |
| Audit controls over ePHI systems (HIPAA 45 CFR 164.312) | Every secret read, lease and revocation is logged with the job identity, time and path requested | Audit device output retained and reviewed, with a sample trace from one pipeline job to one secret read |
| MFA for any individual accessing a system (FTC 16 CFR 314.4) | Engineers who configure pipelines, change policies or approve production jobs sign in with MFA; the jobs themselves do not use MFA | Identity provider MFA policy export and a list of accounts with pipeline admin or approval rights |
| Encryption in transit and at rest (FTC 16 CFR 314.4, HIPAA transmission security) | Secrets travel over TLS from runner to OpenBao and are encrypted in storage before they are written | TLS configuration for runners and storage encryption settings, with the key custody approach documented |
| Logging activity of authorized users (FTC 16 CFR 314.4) | Pipeline configuration changes, policy edits and approval actions are logged alongside secret reads | Change logs from GitLab and OpenBao linked to named people and job identities, forwarded to the log platform |
| Scoped access and least privilege | Each project's jobs can read only the paths their policy names, so one compromised pipeline cannot reach other teams' secrets | Per-project policy files and a test showing a job from one project is denied another project's path |
| Confirming what auditors accept | Auditors decide whether a control is sufficient for your scope; confirm the expected evidence with your assessor before the build | Written agreement with your auditor or counsel on evidence format and retention period |
How pipeline jobs authenticate to OpenBao
OpenBao documents JWT/OIDC as one of its auth methods, and it is the pattern that fits CI jobs best. The GitLab job requests a short-lived identity token that GitLab signs for that specific pipeline and job. The job presents that token to OpenBao, OpenBao checks the signature against the issuer's published keys and the token's claims, and it returns a short-lived OpenBao token scoped to a policy. No secret ID or password is stored in CI/CD variables, so there is no long-lived login credential to leak from a project's settings.
- No stored login secret: The job proves its identity with a token it obtains at runtime, so the variables panel holds only the OpenBao address and role name.
- Claim-based roles: Roles can bind to claims such as the project path, branch or environment, so a job from one project cannot read another project's secrets.
- Short token lifetime: The OpenBao token issued to the job expires with the job, which limits the window for misuse.
- Audit by job identity: Audit entries can record the claims of the job that authenticated, which supports the question of which job read which secret.
- Version-specific configuration: The exact claim names and mapping for GitLab must be confirmed against the OpenBao JWT documentation and the client's GitLab version before any role is written.
Confirm the bound claims, token audience and issuer URL in a test project before rolling the pattern out to production pipelines.
OpenBao recommends AppRole for servers, so it is the appropriate method for self-managed GitLab Runners and build hosts that cannot rely on a CI-issued identity token in every context. AppRole uses a role ID, which is closer to an account name and can be placed in configuration, and a secret ID, which is the credential that must be delivered to the host. The secret ID is the item to protect, so its delivery method and lifetime define the risk. Runners can be given narrow policies so each runner reads only the paths its jobs need.
- Separate role ID and secret ID: The role ID can sit in runner configuration, while the secret ID should be short-lived, single-use where practical, or wrapped and delivered at start-up.
- Per-runner or per-group roles: Assigning a role to each runner pool keeps blast radius small if one host is compromised.
- Bound lifetimes and CIDR limits: Confirm which token and secret ID settings, such as TTLs and source address restrictions, the chosen OpenBao version supports.
- Delivery path: Decide how the first secret ID reaches the host, since a tool such as a configuration management system can become the new place where secrets accumulate.
- Runner upgrades: Runner and OpenBao versions should be tracked together, because the GitLab maintenance policy sets its own cadence for the runner components.
Ask the partner to show how a secret ID is issued, rotated and revoked for one runner, and where that event appears in the audit log.
Many pipelines still authenticate with a static OpenBao token, a username and password, or a secret value pasted into CI/CD variables. These patterns work, but they hold a credential that does not change unless someone changes it, and it is often visible to anyone who can edit the project or inherit its group settings. A token copied into a variable also gives the audit trail a shared identity, so it becomes hard to say which job or person read a given secret. This is the pattern the migration should retire first, and it is usually the one most in need of a written inventory.
- Shared identity: Multiple jobs using one token make it difficult to attribute reads to a single pipeline.
- Broad exposure: Variables can be exposed through project maintainer rights, group inheritance or job logs if masking fails.
- No natural expiry: Static credentials need a manual rotation process that teams often skip.
- Inventory first: Find every variable and file that holds a token, password or key, and record the owning project before changing anything.
- Staged retirement: Revoke each static credential only after the replacement job has run successfully and the audit entries confirm the new identity.
Ask the partner for the inventory method and the list of revocation checks they will run before any static credential is disabled.
Which platforms fit CI/CD secrets and why
Pipeline secrets sit between a source host, a runner that executes jobs, and a secrets store that issues credentials. The options below differ mainly in where they sit in that chain and in their license terms, so the right choice depends on your licensing policy and the tooling you already run.
OpenBao as the secrets store
OpenBao is MPL-2.0 licensed and hosted under the OpenSSF, where it is a Sandbox project. It supports JWT/OIDC login, so a pipeline job can authenticate with its own identity token instead of a stored password. Its dynamic secrets cover SQL databases and Kubernetes, and leases are revoked automatically when they expire. Check which auth role each project maps to and whether your team can operate the storage backend and unseal process.
Infisical for secrets and certificates
Infisical covers secrets, certificates and access, with an MIT-licensed core and a separate enterprise license for content in ee directories. Teams that want a developer-facing interface and CI integrations may find it quicker to adopt. Confirm which features you need sit outside the ee directories, since those carry different terms. Also verify how it handles dynamic database credentials and audit export before committing it to production pipelines.
HashiCorp Vault as a licensing decision
Vault 1.15.0 and later use the Business Source License 1.1, with IBM named as licensor. This is not an OSI-approved open source license, so it is a policy question rather than a technical default. Organizations with open source sourcing rules or existing Vault estates should review the license text with legal before choosing it. Existing Vault pipelines can often be migrated, so ask a partner which parts of your setup map directly to OpenBao.
GitLab CI/CD in the pipeline
GitLab's pipeline features are the trigger and identity source for the job, so their tier determines what your team can use. The pricing page lists advanced CI/CD for Premium, at 29 US dollars per user per month billed annually, with Ultimate custom priced. All three tiers are available for self-managed installations. Confirm which secret-related and compliance features your team needs, then match them to a tier rather than assuming a tier includes them.
GitLab Runner as the execution layer
GitLab Runner executes jobs and is where a job's identity token is issued and where secrets are injected at run time. Runner placement, whether shared, group or project scoped, and the executor type all affect which jobs can reach which secrets. Review how runners are isolated across projects and whether self-hosted runners in your network can reach OpenBao directly. Ask a partner to document the runner trust boundary before you grant any production scope.
Rollout phases for replacing pipeline secrets
This sequence moves a pipeline estate from long-lived CI variables to short-lived, identity-bound credentials in stages, so each phase produces an inventory, a control or a verified cutover before the next one starts. Every phase closes with a named output that the client and the implementation partner can check.
Inventory CI variables and static credentials
The client's engineers and the implementation partner export variable lists from every GitLab group and project, plus any secrets referenced in runner configs, deploy scripts and container images. Each entry is recorded with its owner, the jobs that read it, the target it authenticates to and the date it was last rotated. The output is a single inventory file that the security team signs off as complete for the agreed scope, with a note of any repositories that could not be scanned.
Classify secrets by blast radius
Each inventory entry is scored by what it unlocks: production cloud accounts, production databases, signing keys, package registries and non-production systems. Protected and masked variable settings are checked against the score, since a masked value can still appear in logs if a job prints it. The output is a classified register with a replacement priority for each secret and a short list of credentials that need a rotation before any migration starts.
Design the OpenBao cluster and storage
The partner designs the OpenBao deployment inside the client's own infrastructure, covering node count, load balancing, TLS, unseal and recovery key custody, and backups. The storage backend choice is made here: integrated storage (Raft) is one of the officially supported HA backends, and PostgreSQL is the other, with the OpenBao storage documentation describing PostgreSQL as easier to operate safely than Raft. The output is an approved architecture decision record and a tested failover and restore plan, confirmed in a non-production environment.
Configure JWT auth roles per project and branch
The partner enables the JWT/OIDC auth method and binds roles to specific GitLab projects, groups and protected branches, so a job can only obtain a token matching its own claims. Policies are written per role so a job reads only the paths it needs and nothing else. The output is a role and policy catalogue that the client reviews, plus test jobs proving that an unmatched project or unprotected branch receives no token.
Pilot on low-risk projects
A small set of non-production projects with few dependencies moves first, with jobs changed to fetch secrets from OpenBao at runtime instead of reading CI variables. Pipeline owners run their normal release flow while the security team reviews audit log entries to confirm which job read which secret. The output is a pilot report listing failures, policy gaps and changes made, and a go or no-go decision for the wider rollout, agreed in writing.
Migrate dynamic database and cloud credentials
Jobs that deploy to production databases and cloud accounts are moved to dynamic secrets, where OpenBao issues short-lived credentials for the lease period and revokes them automatically. Each migrated job is tested in staging first, and the old static credential is kept disabled, not deleted, until the job has run successfully. The output is a cutover log per system showing the new credential path, the lease settings and the successful deployment run that proved the change.
Revoke old static secrets
Once a project's jobs have run on OpenBao for an agreed period, its remaining static CI variables and the upstream credentials behind them are rotated and revoked. The client confirms that no pipeline still references the old values by searching job logs and repository configuration. The output is a revocation record per secret with the date, the approver and the verification result, which feeds the evidence pack for the audit.
Run a recurring access review
The client's security owner reviews JWT roles, policies, project bindings and the audit log on a fixed schedule, removing roles for archived projects and tightening any policy that grants more paths than the pipeline uses. Durations between reviews are set by the client's own policy, since the researched facts do not prescribe them. The output is a dated review record with the changes made, the reviewer's name and open findings with owners.
Scoping policies per project and proving which job read which secret
Each CI/CD job should be able to read only the secrets its own project needs, and every read should be traceable to the job that made it. In OpenBao, the JWT/OIDC auth method is where this starts: the pipeline's identity token carries claims such as the project path, the branch or ref, and the environment, and the role you configure can bind those claims so that a token from one project cannot authenticate into another project's role. Each role then attaches a policy that grants read access only to that project's KV paths or dynamic database roles, with path rules scoped to the project prefix. Confirm the exact claim names your GitLab version emits and the bound claim options in the OpenBao JWT auth documentation before you write roles, because a wildcard on a claim is the most common way scope quietly widens.
Production secrets need a second gate beyond the project. Bind the production role to the protected branch or protected environment claim so that only a job running from a protected ref, and in the approved environment, can receive a token with production policies. Keep the policy for merge request pipelines and feature branches separate from the one for deployment jobs, and keep the token time-to-live short enough that a leaked token has little value. Decide who approves changes to these roles, since editing a bound claim is effectively editing who can read production. Recording who approved a change to a role is a separate control from the audit log, and your change management process should cover both.
OpenBao audit devices record each request and response, with the identity and token details of the caller, so a read of a secret shows the path, the auth role and the entity that authenticated. Test this before go-live: run a job against a non-production role, then confirm the audit entry names the expected role and claims. Audit devices can be configured to write to a file or socket, and shipping those entries to a SIEM such as Wazuh is a separate integration you should scope and confirm, including parsing, field mapping and how log loss is detected. Retention is set by your own policy and by the regulations that apply to you, so state the retention period in writing and make sure the log store, not only the vault node, holds the record.
Evidence auditors ask for and which component produces it
This table lists the evidence an assessor is likely to request for a CI/CD secrets design and names the component that produces each item. Use it to plan what to export, retain and review before an assessment, since the sufficiency of each item is decided by auditors and certification bodies rather than by DeployOpen.
| Evidence item | Component that produces it | What to confirm before the assessment |
|---|---|---|
| Auth method and JWT/OIDC role configuration exports | OpenBao JWT/OIDC auth method, exported through its configuration and API | Bound claims for the GitLab issuer, audience and project or branch conditions match the intended design |
| Policy files per project or environment | OpenBao ACL policies stored in version control with change history | Each policy grants only the paths a given project's jobs need, and no wildcard reads cover other projects |
| Audit log samples showing job identity and secret path | OpenBao audit devices, forwarded to the SIEM | Entries record the authenticated role or identity, the secret path read and the time, with sensitive values hashed |
| Lease and revocation records for dynamic credentials | OpenBao lease tracking for dynamic database and cloud secrets | Short TTLs are set, leases expire or are revoked when jobs finish, and revocation runs are logged |
| GitLab project and protected branch settings | GitLab project settings, protected branches and protected CI/CD variables | Only protected branches and tags can request production roles, and runner and project access are restricted |
| Pipeline job configuration showing how secrets are requested | GitLab CI/CD configuration files (.gitlab-ci.yml) reviewed in merge requests | No long-lived credentials are stored as CI/CD variables, and the ID token is requested only in the jobs that need it |
| Access review records for pipeline identities and roles | Periodic review export from OpenBao plus GitLab member and runner access reports | Reviewers sign off on roles, project bindings and stale identities on a documented cadence |
| Backup and restore test records for the secrets platform | OpenBao snapshot or storage backup procedures and restore test logs | Restore tests are dated, performed on a separate environment and show that policies and auth configuration came back intact |
Questions teams ask before moving pipeline secrets to OpenBao
How much effort does migrating pipeline secrets to OpenBao take?
Effort depends on the size and shape of the estate, not on the OpenBao installation alone. The main drivers are the number of GitLab projects and pipelines, how many database and cloud integrations need short-lived credentials, and how the GitLab instance is laid out (single node, high availability, or multiple instances). Each pipeline that reads a static secret needs its job to authenticate, its policy to be scoped, and its variable to be removed or rotated. Ask any partner for a written inventory of projects, pipelines, secret variables and target systems before accepting a quote, because that inventory determines the scope.
Can our team migrate pipeline secrets to OpenBao without a partner?
A small estate can often be handled in-house if the team already has working OpenBao and GitLab skills. The copying of secrets and the JWT/OIDC login configuration are routine once the pattern is chosen. The costly part is the design: how roles map to projects and branches, which secrets become dynamic, how unseal and recovery keys are held, and how job-level audit records reach your SIEM. Those decisions are hard to reverse, so teams that go it alone often review them with an outside architect before rollout. Confirm your own skills against the scope before deciding.
What keeps costing time after the migration is done?
Several things recur. The OpenBao cluster needs monitoring, certificate renewal, and planned upgrades, and its storage backend needs its own care: the OpenBao documentation describes PostgreSQL as easier to operate safely than Raft. Backups and restore tests must be repeated on a schedule. GitLab itself adds recurring work, since its major release cadence, monthly minor releases and twice-monthly patch releases mean regular upgrades, and the upgrade paths require stops at specific versions such as 18.2, 18.5 and 18.8. Each new pipeline or database integration also adds a small ongoing task. Budget for these as operations time, not as one-off project cost.
Does the HashiCorp Vault license force us to move to OpenBao?
Not automatically. Vault version 1.15.0 and later is licensed under the Business Source License 1.1 with IBM named as licensor, which is not an OSI-approved open source license. Whether that matters depends on your legal review of how you use Vault, your procurement policy on source-available software, and whether you need a fork with an MPL-2.0 license. Confirm the terms that apply to your version and deployment with counsel. OpenBao is a fork under MPL-2.0 and is hosted under the OpenSSF, so teams with an open source requirement often evaluate it for that reason.
Is Infisical a substitute for OpenBao in CI/CD?
Infisical can cover similar secret-delivery needs, and it is licensed under MIT except for content in ee directories, which carries a separate enterprise license. The decision should rest on the features you need. Compare how each platform authenticates pipeline jobs, how it issues short-lived cloud and database credentials, how it supports your required high availability and storage design, and how its audit logs export to your SIEM. Check which capabilities sit in the enterprise-licensed parts before you rely on them. OpenBao is a strong fit when dynamic secrets and a documented auth method catalog matter most, but both options need a proof of concept against your own pipelines.
How does an air-gapped GitLab change the OpenBao design?
An air-gapped GitLab changes three things: how software arrives, how secrets reach jobs, and how upgrades are staged. GitLab documents running self-managed instances in offline environments, with separate guidance for its security scanners, so you must plan for offline updates and container images. OpenBao must be reachable from the GitLab runners on the isolated network, which means no reliance on external identity or cloud key services for unseal. Plan an internal PKI for certificates and test backup and recovery without any external service. Confirm offline update procedures with GitLab and your network team before design freeze.
What do we need to give a partner before work starts?
A partner needs enough access to see the real estate and make the design decisions. Provide read access to the inventory of GitLab groups, projects, pipelines and CI/CD variables, plus a list of the database and cloud accounts that jobs use. A GitLab administrator must confirm runner types, the GitLab topology and the upgrade state. The owners of each cloud account and database must approve the dynamic credential roles, and a security owner must agree on unseal and recovery key custody and audit log destinations. Confirm these owners and access grants in writing as part of the scope.
Questions to ask an implementation partner for CI/CD secrets
Start with identity mapping, because it decides whether the whole design holds. Ask how the partner maps GitLab job identity claims, such as the project path, branch, ref type and runner environment carried in the job's OIDC token, to OpenBao JWT/OIDC roles and bound claims. Ask what happens when GitLab changes claim formats between versions: who reviews the token payloads after each upgrade, whether the bound claims are tested in a staging cluster first, and how a broken role fails (closed or open). Also ask how runners that cannot reach OpenBao are handled, for example whether the design relies on self-managed runners in the same network segment, and what the fallback is when a job must still deliver a credential. Get the answers in writing before any pipeline is changed.
Ask how existing CI/CD variables are migrated without breaking pipelines. A credible answer inventories every masked and protected variable, classifies it as static, dynamic or certificate material, and moves jobs in batches, keeping the old variable until the new retrieval path has run successfully on each protected branch. Ask how HA and backups of the OpenBao cluster are tested, including a restore into an isolated environment and a failover drill, and how the partner records the results. Ask how audit logs reach the SIEM, which fields are shipped (client identity, role, path, policy, timestamp), and whether a job-to-secret read record can be produced for an auditor on demand. Finally, ask how per-project policies are documented, and how the support model covers GitLab upgrade stops and security backports, which apply only to the previous two monthly releases. Confirm the response windows in the contract.
Deployment patterns for GitLab and OpenBao
Can OpenBao run on virtual machines with integrated Raft storage for CI/CD secrets?
Yes, integrated storage (Raft) is one of the documented storage backends for OpenBao, and it is one of the two officially supported high availability backends. In this pattern, three or more OpenBao nodes run on VMs in your own cloud account or data center, and an active node holds the lock while standbys forward or redirect requests. The main operational work is node lifecycle, Raft snapshot backups, unseal key custody and upgrades across the cluster. Confirm the node count, disk and network requirements against the OpenBao storage and HA documentation before you size the environment, and test failover as part of acceptance. Teams that already run VM fleets and want OpenBao to own its own storage usually prefer this option.
Is PostgreSQL a better storage backend than Raft for OpenBao?
PostgreSQL is a documented backend and the OpenBao storage docs describe it as easier to operate safely than Raft. It suits organizations that already run a hardened, backed-up PostgreSQL service with a database team that can support it. OpenBao HA uses the database to hold the active node lock, and since OpenBao 2.7.0 standbys can serve read-only operations on PostgreSQL as well as Raft, which gives horizontal read scaling. The trade-off is a dependency on the database's own availability, backup and failover design, which must be tested alongside OpenBao. Ask your team to confirm the database version, replication setup and restore procedure with the vendor documentation before committing to this path.
Where should OpenBao sit relative to a self-managed GitLab instance?
Place OpenBao on a network segment that GitLab Runners and the GitLab job environment can reach over TLS, and keep it close enough that latency and failure domains are predictable. Many teams put the OpenBao cluster in the same region or data center as the GitLab instance, and avoid co-locating it on the same hosts, so a GitLab outage or upgrade does not take the secrets service down with it. The JWT/OIDC auth method lets jobs authenticate using the GitLab identity token, so the trust relationship and the allowed claims should be reviewed as part of the design. GitLab reference architectures scale from 1,000 users to 50,000 users, and the docs generally recommend a high availability strategy for 3,000 or more users, so confirm sizing for your user count in those documents.
Can GitLab's stateful components run inside Kubernetes with OpenBao?
The GitLab reference architectures documentation says running stateful components such as PostgreSQL and Redis inside Kubernetes is not supported. The supported pattern is the Cloud Native Hybrid architecture, which runs stateless components on Kubernetes while stateful services run on VMs or managed services. This matters for the secrets design because the database and cache that GitLab depends on should not be placed in the same cluster you use for ephemeral runner workloads. OpenBao can still run on Kubernetes if your platform team is comfortable operating it, but storage and HA choices should be made separately from the GitLab layout. Confirm the current support statement in the GitLab reference architectures documentation before finalizing the topology.
How do offline or air-gapped GitLab runners get secrets from OpenBao?
Runners on isolated networks need a path to OpenBao that stays inside your environment, which usually means an OpenBao cluster on the same isolated network or a reachable segment with strict firewall rules. GitLab documents running self-managed instances in offline, air-gapped environments, and it provides separate guidance for running its security scanners offline, so review that material for the runner and scanner side. Plan how OpenBao itself receives updates, how unseal keys are held without an external cloud KMS, and how the JWT or AppRole trust is configured without reaching a public identity endpoint. For runners that cannot reach GitLab.com or a public OIDC issuer, the JWT issuer must be your own GitLab instance. Confirm each of these steps with your security team and the vendor documentation during design.
Which GitLab and OpenBao versions should a deployment track for upgrades?
Track both products on a documented upgrade cadence and test each step in staging first. GitLab ships a minor release on the third Thursday of each month and patch releases twice a month, and it currently maintains 19.5, 19.4 and 19.3. GitLab requires upgrades to pass through upgrade stops, which fall at versions x.2, x.5, x.8 and x.11 since GitLab 17.5, so an upgrade cannot skip them. For OpenBao, the current releases in the supplied facts are v2.7.1 and v2.6.4 on the previous minor line, with v2.7.0 released earlier. Confirm the supported upgrade path for your exact versions with the OpenBao migration guide and the GitLab upgrade documentation before scheduling changes.
Can DeployOpen implement and test this pipeline secrets pattern in our environment?
DeployOpen plans, implements, customizes, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside the client's own infrastructure, including cloud accounts, data centers and air-gapped networks. For this pattern, that work covers the OpenBao topology and storage choice, the GitLab trust and JWT configuration, runner placement, backup and restore testing, and documentation for your auditors. Most engagements are fixed-scope, so the topology, deliverables and timelines are agreed in writing before work starts. DeployOpen does not publish a price list, and a quote follows from that written scope. DeployOpen prepares evidence for compliance assessments but does not issue audit reports or certifications.
What drives the cost of running OpenBao and GitLab in this pattern?
The main cost components are the software licenses, the infrastructure and the people who operate it. OpenBao is licensed under MPL-2.0, so there is no per-secret license fee for the software itself, but you pay for the nodes, storage, load balancing, backups and operations time. GitLab Free costs 0 US dollars, and the GitLab pricing page lists Premium at 29 US dollars per user per month billed annually, with Ultimate custom priced, and all tiers available for self-managed installations. The cost drivers include the number of nodes, whether PostgreSQL is managed by a database team, the number of users and runners, and how much offline support is needed. Ask any quote to itemize one-time setup, recurring infrastructure, support retainers and each licensed GitLab tier.
How DeployOpen would scope this work
DeployOpen works from a written scope agreed before any build starts. For a CI/CD secrets project, that scope names the pipeline platforms in use, the OpenBao cluster that will serve them, the cloud accounts and databases that will issue short-lived credentials, and the projects and environments in the first wave. Most engagements are fixed-scope, so deliverables, acceptance checks and the handover package are written down up front. Ask each bidder to state in writing what is excluded, such as migration of secrets in projects outside the first wave, changes to application code and any work on the pipeline platform itself.
The work normally moves through five phases. The first is an inventory of every place a pipeline holds a credential today: CI/CD variables, protected and group-level variables, cloud keys stored as files, and database passwords embedded in scripts. The second is design, which covers the JWT or OIDC trust between the pipeline platform and OpenBao, the role and policy model per project, the secret engines to enable, and the audit log destination. The third is build, followed by migration, where pipelines are switched over project by project and legacy static values are revoked. The last phase is handover, with runbooks, policy documentation and a walkthrough of how to read the audit trail for a given job.
Ongoing upgrades, backups testing, policy reviews and continuous security testing are not part of the initial build. They can be covered by a separate retainer, which DeployOpen offers for ongoing support, upgrades and testing. Before signing, confirm which of these your team will own internally, because that determines whether a retainer is needed at all. DeployOpen does not publish a price list, so ask for a quote that separates the one-time build from any recurring retainer.
How DeployOpen builds and supports CI/CD secrets management
DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For CI/CD secrets management, that means replacing long-lived pipeline credentials with OpenBao authentication, short-lived credentials and per-project policies, each agreed in writing before work starts.
How we scope
- Inventory every pipeline credential, runner and project that reads secrets today, including those stored in CI variables.
- Agree in writing which GitLab instances, runners, cloud accounts and databases fall inside the engagement.
- Define the target auth methods, policy-per-project model and audit log destination before any build starts.
How we build
- Deploy OpenBao with its storage backend, high availability design and unseal approach sized to your environment.
- Configure JWT/OIDC login from pipeline jobs, with roles limited to the project, branch and job identity they serve.
- Test that a job can read only its own secrets, and that expired or revoked credentials stop working.
How we hand over
- Document policies, roles, dynamic secret paths, rotation settings and the runbook for adding a new project.
- Deliver the audit logging configuration and the evidence needed to show which job read which secret.
- Train platform and security staff to review policies, respond to access requests and perform recovery steps.
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer, sized to the written scope.
- Plan OpenBao version upgrades and GitLab upgrade stops as separate, scheduled changes with rollback steps.
- Retest pipeline access paths after significant changes to runners, projects or cloud roles.
