OAK: add OpenBao NGINX reverse proxy and Rails URL inference

João Alexandre Cunharequested to merge
9668-oak-openbao-nginx into master

What does this MR do?

Part 1 of 2 for #9668 (closed) (OpenBao integration for OAK Beta). Helm values generation follows in !9290 (merged), stacked on top of this one.

When oak['components']['openbao'] is enabled, gitlab-ctl reconfigure now:

  1. Adds a domain-based NGINX server block (server_name derived from oak['components']['openbao']['external_url']) that proxies all traffic to the configured OpenBao internal URL.
  2. Auto-infers gitlab_rails['openbao']['url'] and internal_url from OAK config, respecting any values already set by the operator in gitlab.rb.

New configuration

oak['components']['openbao']['enable']       = true
oak['components']['openbao']['internal_url'] = 'http://10.0.0.5:8200'  # full URL (LoadBalancer, NodePort, etc.)
oak['components']['openbao']['external_url'] = 'http://openbao.example.com'

Omnibus is agnostic to how the Kubernetes service is exposed — only the internal_url the operator configures matters.

Architecture notes

  • All OpenBao component settings (user-facing and derived) live under oak['components']['openbao']. The top-level oak['...'] namespace is reserved for keys shared across all components (enable, network_address).
  • Oak::OpenBao.parse_external_url runs at compile time (priority 19) to pre-calculate fqdn and listen_port from external_url, following the same pattern as the Container Registry integration.
  • The nginx recipe reads these pre-calculated node attributes at convergence time.

Testing

  • Unit tests for Oak::OpenBao.parse_variables (URL inference, user override respected, validation errors)
  • Unit tests for NGINX template rendering (listen address/port, server_name, proxy_pass, headers)

Related issues

Closes #9668 (closed) (partial — this MR covers the NGINX proxy and URL inference only)

Builds on top of !9235 (merged) (OAK Cookbook).

Checklist

See Definition of done.

For anything in this list which will not be completed, please provide a reason in the MR discussion.

Required

  • MR title and description are up to date, accurate, and descriptive.
  • MR targeting the appropriate branch.
  • Latest Merge Result pipeline is green.
  • When ready for review, MR is labeled workflowready for review per the Distribution MR workflow.
  • The UBT version and corresponding checksum hash have been updated and referenced in the merge request if applicable.
    • UBT EE pipeline (Trigger:ee-package-ubt) is green

For GitLab team members

If you don't have access to this, the reviewer should trigger these jobs for you during the review process.

  • The manual Trigger:ee-package jobs have a green pipeline running against latest commit.
  • If config/software or config/patches directories are changed, make sure the build-package-on-all-os job within the Trigger:ee-package downstream pipeline succeeded.
  • If you are changing anything SSL related, then the Trigger:package:fips manual job within the Trigger:ee-package downstream pipeline must succeed.
  • If CI configuration is changed, the branch must be pushed to dev.gitlab.org to confirm regular branch builds aren't broken.

Expected (please provide an explanation if not completing)

  • Test plan indicating conditions for success has been posted and passes.
  • Documentation created/updated.
  • Tests added.
  • Integration tests added to GitLab QA. — Not applicable for this MR; integration testing covered by the OAK e2e environment.
  • Equivalent MR/issue for the GitLab Chart opened. — Not applicable; OpenBao runs in a separate Helm chart (not the GitLab chart).
  • Validate potential values for new configuration settings. — Validated in Oak::OpenBao.parse_variables: internal_url and external_url scheme/host/port.
Edited by Hossein Pursultani

Merge request reports