Does Pulumi automatically refresh expired Azure AD service‑principal secrets?

Question

Goal: Determine whether Pulumi can automatically detect and renew an expired Azure AD service‑principal secret when using static credentials, while maintaining least‑privilege access.

Constraints/uncertainty: Pulumi reads the secret from environment or config per command; static secrets are not auto‑refreshed, whereas Managed Identity or OIDC flows rely on the underlying Azure SDK to obtain fresh tokens. It is unclear if the Pulumi CLI or provider exposes a hook for external secret rotation or if users must implement their own refresh mechanism.

Does Pulumi CLI provide a callback or environment variable to trigger secret retrieval just before a command runs?
Can the Azure SDK’s DefaultAzureCredential be used with Pulumi to handle rotation without changes to the stack?
What is the recommended pattern for integrating external secret‑rotation tools (e.g., Azure Key Vault) with Pulumi stacks to avoid manual token updates?

Tasadduq Burney · Answer

Short answerNo. Pulumi does not automatically refresh or rotate expired Azure AD (Microsoft Entra ID) service-principal secrets—neither the credentials Pulumi uses to authenticate to Azure, nor secrets it manages as resources such as azuread.ApplicationPassword. Pulumi is a declarative provisioning tool, not a secret lifecycle manager. Rotation must be triggered externally, typically by a scheduled CI job.Two separate cases, both manualIt is important to distinguish between the two types of secrets involved:Provider authentication credentials: If Pulumi authenticates to Azure with a static client secret (e.g., ARM_CLIENT_SECRET), the Azure SDK refreshes short-lived access tokens during a run, but the underlying client secret is never renewed. When it expires, pulumi up fails with an authentication error until the environment or Pulumi ESC/config is updated.Secrets managed as resources: An azuread.ApplicationPassword has a fixed endDate. When that date passes, Pulumi does nothing automatically; the resource only changes if you modify its inputs and execute a stack update.Answering your specific sub-questionsPre-command credential hook: There is no Pulumi CLI callback to re-fetch a secret immediately before a command. Pulumi ESC can reference a secret store (like Azure Key Vault) to resolve values at runtime, but ESC resolves the current value; it does not rotate an expired secret.DefaultAzureCredential: Yes, the Azure provider can use the standard Azure SDK credential chain (Azure CLI, Managed Identity, or OIDC federation). Switching to OIDC workload identity federation or Managed Identity eliminates expiring secrets entirely, which is the recommended path for provider authentication.External rotation pattern: For secrets managed as resources, the common pattern is to store a rotation timestamp or counter in stack config and wire it into the password resource (using rotateTriggers or replace_triggered_by, depending on your provider version). A scheduled CI job then bumps the value and runs pulumi up before the secret expires.Verification and caveatsVerify your installed provider version with pulumi plugin ls, as rotation-related input names vary across pulumi-azuread releases. Note that replacing an ApplicationPassword invalidates the old secret immediately; ensure consumers can pick up the new value to avoid downtime. You can verify the lack of auto-rotation by creating a password resource with a very short endDate and running pulumi preview after it expires; no change will be detected.One diagnostic detail to consider: if your goal is strictly provider authentication, moving to OIDC federation is generally preferable to building a custom rotation pipeline.

Does Pulumi automatically refresh expired Azure AD service‑principal secrets?

1 answer

0 question comments

Short answer

Two separate cases, both manual

Answering your specific sub-questions

Verification and caveats

Your perspective belongs here.