Turnkey Azure Key Vault setup: secrets, keys, certificates

Configuring Azure Key Vault: where secrets and keys leak

Almost every leak starts not with a breach, but with convenience. A database connection string settles in an application config file, a password in an environment variable on a staging environment, and an access key to the secrets vault lies right in a deployment script.

The file ends up in a repository, the repository in an external copy, and then the secret lives in commit history even after the string has been removed.

A separate story is access keys issued "temporarily." They are received by a build agent, an analyst for debugging, a contractor for the duration of a project.

A month later no one remembers which of them are still used, so rotation is not performed: revoking a working key is scary. Thus one perpetual access outlives several team changes.

Certificates break services not because they are hard to issue, but because rotation is not set up.

A private key is stored on one machine, renewal is done manually after someone else's reminder, and once the expiration date passes, rollback no longer helps — there is nowhere to place a new certificate without stopping the service.

And the most costly in consequences: access to environment secrets is not separated.

The test environment and production environment read the same set of application passwords, a developer sees production credentials, and during incident analysis it is impossible to answer who accessed a secret and when. We break down how this is closed at the level of the vault, access policies, and rotation.

What managed storage of secrets and keys provides

Secrets live longer than their owners: connection strings settle in configuration files on servers, in environment variables of build agents, and in chats. When an engineer leaves a project, revoking access turns into a search — where else this key is listed and who uses it. While the search is underway, the key remains active.

Azure Key Vault eliminates local copies as a class: a secret is stored in one place, and the application retrieves it using its own service account, not via a shared string in a file.

Permissions are granted by roles at the level of an individual secret, so the build agent reads only what it actually needs. Changing a value does not require config edits or an environment restart — the service picks up the current version on the next access.

Secret rotation and key lifecycle management are moved to a schedule: expiration, advance notification, certificate reissue without downtime.

A key retains versions — if the new one does not work, rollback to the previous one takes minutes and does not require restoring from a backup.

Auditing access to secrets answers the question "who saw this": the log records the account, time, and object of access. Revoking access is one operation that takes effect immediately, because there is nothing to revoke on the application side.

Rotation time is reduced from hours of manual work to minutes, and failures due to expired certificates and forgotten keys disappear along with manual config edits.

Options for connecting applications to the secrets vault

There are several ways to connect a service to the vault, and the choice between them is not a matter of taste, but of whether the service can authenticate itself.

A managed identity is the baseline option: the platform issues a token, and neither a password nor a connection string remains in the code, while access is revoked together with the resource.

A service connection is needed where this is impossible — permissions are granted by a separate account with a reduced role. Network restrictions do not replace authentication, but narrow the perimeter from which the vault is accessible at all.

In practice, the modes are combined: internal services use identities, the vault is closed by a private endpoint and a subnet list, and accounts remain only for external consumers.

Such a set gives a verifiable picture — you can see who accesses secrets, and it is clear what will happen when access is revoked.

Implementation procedure: from secret audit to handover

We structure the work order so that migration does not legitimize the existing mess: first a complete picture of secrets and their owners, then the access scheme, and only then migration.

Each stage ends with a verifiable artifact — a secret map, a role matrix, or the results of control scenarios.

1. Secret audit. We inventory password vaults in repositories, pipeline variables, application configurations, and files on servers. For each record, we record the owner, criticality, lifetime, and duplicates — without this, rotation and deletion are impossible.
2. Access separation scheme. We separate vaults by environment and grant roles for specific secrets instead of permissions for the entire environment. Workloads read values through managed identities, service accounts with long-lived keys are decommissioned, and public access is closed.
3. Secret migration. We migrate in stages, with versioning and reconciliation of values against the reference. We switch applications and pipelines to reading from the vault, mark old copies for deletion, and remove them after a control period.
4. Rotation setup. We set the lifetime and schedule for changing passwords and keys, automate renewal and owner notifications. We separately verify that the service picks up the new version without restart or manual intervention.
5. Failure testing. We run scenarios: vault unavailability, revoked access, a forgotten secret, accidental deletion. We enable protection against irreversible loss and recovery from backup.
6. Acceptance and handover. We verify permissions from each environment against control scenarios and hand over the vault map, role matrix, rotation policy, and recovery procedure. The on-call team receives instructions and a breakdown of typical incidents.

Access policies, roles, and key storage schemes

After going live, you are left not with a set of settings that "work as we made them," but with a managed environment: a role model, separated environments, and written policies.

We hand it over as a checklist that a new engineer can understand without a chat history, and you can accept the work item by item.

• Roles and access rights. A "who can do what" matrix: vault administrator, secret owner, service consumer with read-only access. Permissions are least-privilege, with a separate principal for each, and no shared accounts.
• Environment separation. Development, pre-production, and production live in separate vaults with their own permissions: a leak of test values does not open access to production ones.
• Vault policies. Soft delete and purge protection, network restrictions, and logging of access to secrets with export to general monitoring.
• Secret rotation policy. For each class: lifetime, owner, procedure for issuing a new version, and rollback to the previous one without stopping the service.
• Certificate rotation. An auto-renewal scheme, a calendar of advance notifications before expiration, and a person responsible for manual issuance if auto-renewal is unavailable.
• Secret documentation. Vault map: name, purpose, owner, consumer, rotation period, recovery procedure.
• Access granting and revocation. How access is requested and what is removed when an employee leaves or a service is decommissioned.

We go through this checklist together with your team before handover — we close discrepancies before transfer, not after.

Case study: how secrets moved from configurations to the vault

The customer is a product team with three environments and 30+ services: database connection strings, external API keys, and certificates were stored in environment variables and repository manifests.

Rotating one key meant manually going through services, and a person leaving with access triggered secret changes across the entire environment. One forgotten manifest — and production returned an authorization failure while application instances were fully alive.

What was changed

Secrets moved to Azure Key Vault with access via managed identities: the application receives a value by role, and there is no longer a password or key in the configuration.

Vaults were separated by environment, permissions were granted to groups, and versioning retained previous values for rollback. Certificates were switched to auto-renewal — the current version is fetched at startup, without manual replacement.

Metrics before and after

The migration covered 34 services. Failures due to expired certificates and mismatched keys — 3-4 per quarter — disappeared: renewal happens without human involvement.

Rotating a key takes one operation instead of a planned window with going through teams, and restoring access after an employee change takes minutes instead of hours.

The secret scanner stopped finding values in repositories, and the vault access log showed the real service connections: you can see who reads what, and excess permissions are removed based on fact, not memory.

How a secrets vault differs from environment variables

A common debate: if a secret fits in an environment variable, why have a separate vault? The difference is not convenience, but the trust boundary.

A process receives environment variables at startup, and after that they are visible to anyone who has access to the host, the container description, or a process dump during a failure.

Configuration files cover another part of the task: they are versioned, reviewed, and rolled back. But a secret in a repository lives longer than the access of the person who put it there, and encrypting the file simply shifts the question to the key holder.

A managed vault separates access and value: the application receives a secret by its identity, permissions are granted by role, and key and certificate versions change separately from the release. In Azure Key Vault, this is confirmed by the access log — you can see who read a secret and when.

The choice of storage method comes down to three questions: what happens if the value ends up in a log, who can change it and how quickly, and how to revoke access from an employee who has left. If the answer to at least one is "there is no way" — such a value belongs in a vault.

Frequently asked questions about integrating the vault with services

The doubts concern not the configuration itself, but the system's behavior when something breaks: the vault is unavailable, the service lives outside the cloud environment, a secret needs to be changed without a restart, or access needs to be transferred to another team. Below are answers to the scenarios that most often come up in an architecture review.

How do services outside the cloud connect?

An external service connects via a private channel or by an allowlist of addresses — no open access from the internet remains. We issue each consumer a separate identity and a minimal role, so one compromised set of permissions does not open the other secrets.

How does rotation happen without downtime?

Changing a secret means two versions living at the same time: applications accept both the old and the new one, then the old one is disabled. For databases, the order is this: first change the password in the system itself, then the version in the vault. No restart is needed — the new version is picked up by event or by timer.

What about access after project handover?

Permissions are described as code: owners, roles, and identities are stored in the repository, so handing over to a team means changing the owner and revoking excess roles, not manually going through the console.

In an emergency, a separate procedure applies: access by request, for a limited time, with an entry in the log.

Let's discuss the task and come back with an estimate and work plan

To come back with a work estimate and implementation plan, we need not a full documentation package, but a snapshot across several points.

With this set of initial data, we determine the scope of work, the vault separation scheme in Azure Key Vault, and the migration order in one pass — without clarifying rounds and two weeks of correspondence.

• A list of services and applications that need secrets, keys, or certificates: name, environment (production, pre-production, test), and the customer-side owner.
• Current storage location: configuration files in the repository, environment variables on servers, a custom solution, scattered records among administrators — as is, without cleaning them up.
• Access requirements: which teams and roles read secrets, who issues and revokes them, whether environment isolation is needed and whether reading production values from the test environment is prohibited.
• Environment requirements: cloud or hybrid scheme, availability of private endpoints, how services authenticate each other, and whether separate environments are needed for sensitive data.
• Lifecycle rules: expiration of secrets and certificates, rotation frequency, procedure for compromise, where access logs are stored and for what retention period.
• Timeline constraints: windows when switches are allowed, critical periods such as financial reporting close, and the change approval procedure.
• Acceptance criteria: what we consider the result — the service receives a secret automatically, without manual intervention, and rollback to the previous scheme has been tested in the test environment.

Describe the picture as it is, even if keys are currently shared in chats: the more accurate the initial data, the fewer assumptions in the estimate. In response, we will send a stage plan, scope of work, responsibility allocation, and starting point.