[Hiring] Senior Vault Engineer @Atyeti

Role Description

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.
• 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.
• Consumption patterns:
  • 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:
  • 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.
  • 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.