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
integrate.
Page 1 of 4
Synopsys Vault Adoption: Recommended RSA Engagement Plan
same modules.
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.
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.
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 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.
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.
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
Job details are sourced from the employer's original posting.
Open job postingAbout the company
Atyeti is a cloud consulting company that helps clients with cloud transformation, compliance, and risk management. They specialize in multi-cloud, zero-trust deployments and policy-driven workflows.