Skip to main content

Migration

Migration replaces a long-lived static secret with a short-lived, Mint-issued identity. It is the preferred remediation for any secret that is actively used.

Supported Integrations​

Secret migrations depend on third-party providers supporting Workload Identity Federation (WIF).

For workloads running in Kubernetes, the following integrations are supported:

For workloads running in agentic runtime platforms(Bedrock and Gemini EAP), the following integrations are supported:

Ledger recommends migration for a long-lived secret when the following conditions are satisfied:

  1. The Mint installation has been detected. This is required to predict the SPIFFE ID that will be used by this workload.
  2. A static secret is detected as part of the workload's configuration.
  3. A matching static secret is detected in the upstream provider.
  4. The combination of workload platform and upstream provider is one of the supported combinations listed above.

What does the workflow look like?​

Ledger walks you through the following steps, providing detailed guidance based on the target workload platform and upstream provider:

  1. Review the target workload and secret.
  2. Create the trust relationship for Mint in the upstream provider. This includes the target workload's SPIFFE ID and the Mint OIDC provider.
  3. Modify the workload to consume a Mint identity (e.g. JWT-SVID).
  4. Verify the workload is requesting and receiving Mint-issued identities.
  5. Monitor the original static secret to make sure it is no longer in use.
  6. Delete the original static secret from the upstream provider.

Ledger automatically moves between these steps as they are completed, but you may need to re-run an integration scan to refresh the inventory and detect changes in the workload configuration.

Outcome​

The workload no longer relies on a standing secret. Identities are issued on demand, scoped narrowly, and expire automatically. Upstream providers accept the Mint-issued identity.