Sr Vault Engineer

Purpose

This plan captures what an IBM HashiCorp Resident Architect (RSA) would do to move

Synopsys from per-team namespaces to a self-service, pattern-based Vault onboarding

model. It is based on the recommendations from the June 5 and June 26 working sessions

with the Synopsys Vault team. An RSA is onboarded into your environment as a contractor

and builds alongside your Vault team, typically for a short engagement of around 3

months part-time.

Current state

Synopsys has been running Vault for about a year, with a few teams in production and

many in dev. Onboarding is automated for namespace creation only. Everything after that

falls to each team.

Namespace model: Root namespace, then an admin namespace, then one namespace

per team or application group. Teams receive namespace-level admin and manage their

own auth methods, policies and secret engines.

Onboarding flow: ServiceNow request, then the Vault team adds namespace and user

details to Terraform and pushes the change, which triggers the pipeline that creates

the namespace and policies. Teams then configure Vault themselves through the CLI,

UI or code, guided by an internal wiki.

Consumers: GitHub Actions and Azure DevOps pipelines, plus Kubernetes pods.

Human users authenticate through Okta.

Organization: No central platform team. Application teams have their own DevOps and

infrastructure engineers.

Challenges raised by the team

• Many consuming teams are new to Vault and need significant hands-on help to

integrate.

• Vault team effort grows with every team onboarded.

Page 1 of 4

Synopsys Vault Adoption: Recommended RSA Engagement Plan

• Teams on different CI platforms (Azure DevOps, GitHub, others) can't easily share the

same modules.

• No clear path to change models without disrupting teams already in flight.

Recommended target state

The target is a model where the Vault team's onboarding work is approving a request, and

a new team reaches its first secret in minutes.

Namespace model: The root namespace is reserved for platform administration.

Application teams onboard into a shared namespace and are isolated from each other

by ACL policies, not by separate namespaces. Additional namespaces are used only for

business-unit or operating-team boundaries.

Consumption patterns: Two or three packaged, end-to-end onboarding paths that

cover most use cases, built highest impact first. For Synopsys, the likely patterns are:

GitHub Actions pipelines, JWT/OIDC auth, KV secrets

Azure DevOps pipelines, JWT/OIDC auth, KV secrets

Kubernetes pods, service account auth, KV secrets

Okta for human access to manage each team's secrets

Self-service onboarding: A central onboarding repo in Azure DevOps. A team opens a

pull request with a short request file listing team name, application ID, distribution

email, Okta groups and pipeline or workload identities. The Vault team approves, and

Terraform provisions roles, policies and secret paths.

Welcome output: Each onboarded team gets generated instructions covering login, its

secret path, a seeded test secret and a ready-to-use pipeline snippet.

Two tracks: The paved path is the default. Experienced teams that need more

autonomy can be supported on a separate, agreed path.

Discoverability: Vault is documented as the secrets manager of record in an internal

catalog or wiki, so teams find it on their own.

Engagement plan

The RSA works inside your environment alongside the Vault team, in five phases. Each

phase builds on evidence from the one before it.

• Discover and assess

Page 2 of 4

Synopsys Vault Adoption: Recommended RSA Engagement Plan

Meet with the Vault team, key stakeholders, and one or two application teams

(current users or onboarding candidates).

Collect data on a set of onboarding candidates: application ID, platform, runtime,

language, and where it runs (pipelines, Kubernetes, cloud, on-prem).

Identify the prevailing client personas and the viable auth method for each.

Scope which secret types and usage to support first.

• Design the target model

Define the namespace strategy: root reserved for platform administration,

namespaces only for business-unit or operating-team boundaries, ACL policies for

team-level isolation.

Select two or three consumption patterns, prioritized by highest impact and lowest

effort.

Agree on the onboarding request format (YAML or HCL) and the approval flow.

• Build the onboarding automation

Build a Terraform module per consumption pattern that turns a handful of high-level

inputs into the full Vault configuration (roles, policies, secret paths).

Stand up a central onboarding repo in Azure DevOps with documentation and a

request template. Any team can open a pull request, so teams on other CI platforms

don't need to run the modules themselves.

Wire approval to a Terraform pipeline that provisions access automatically.

Use Terraform templating to generate a welcome message: login URL, required Okta

group, secret path, a seeded example secret, a pipeline snippet, and links to docs

and support.

• Pilot and iterate

Onboard a small cohort of willing teams that covers each pattern, and gather

feedback on what works and what isn't clear.

Expand to more teams with documentation only, treating them as beta testers.

Graduate to fully self-service pull requests, opening access gradually.

• Migrate and drive adoption

Route all new onboardings to the shared-namespace model while existing teams

keep running where they are.

Communicate the new model internally and set a re-onboarding window (around 12

months) for existing teams, with self-service tooling such as KV secret migration.

Page 3 of 4

Synopsys Vault Adoption: Recommended RSA Engagement Plan

Define the advanced-team path for teams that need their own namespace, by

agreement.

Establish Vault as the secrets manager of record: internal catalog or wiki presence,

a road show for business-unit leads, and a community channel.

What success looks like

The Vault team's onboarding work is reviewing and approving a request.

A new team goes from request to reading a test secret in its pipeline in minutes.

Two or three patterns cover roughly 80% of onboarding requests.

Vault team effort no longer grows in step with the number of teams onboarded