Least privilege failed my Pulumi run, and that is the point of this weeks agent debate

Description and use

Using a write‑only Chronosphere token with Pulumi caused administrative operations to fail, illustrating that least‑privilege tokens can render automation useless.

Problem

Using a write‑only Chronosphere service account token with Pulumi caused administrative operations to fail, exposing the limits of least‑privilege tokens for infrastructure automation.

Outcome

The Pulumi run failed because the write‑only token lacked necessary permissions, demonstrating that least‑privilege tokens can render automation useless. The lesson is to use unrestricted tokens only when needed, rotate them, and monitor their use.

Workflow

• 1. Configure Pulumi to use Chronosphere provider. 2. Set CHRONOSPHERE_API_TOKEN to the existing write‑only ingestion service account token. 3. Run Pulumi deployment. 4. Observe failures on administrative operations.
• 5. Recognize that provider requires unrestricted or SysAdmin token.
• 6. Update token to unrestricted SysAdmin token and re‑run Pulumi.
• 7. Implement token rotation, expiry, and live monitoring for powerful tokens.

Evidence

You wire up the Chronosphere Pulumi provider with the token you already have lying around, the ingestion service account. It is write-only. It feels like the safe, least-privilege choice. It also does not work.

Source

Pulumi is doing administrative tasks, so the provider needs an unrestricted service account token or a SysAdmin token, set as CHRONOSPHERE_API_TOKEN. Anything less gets blocked on nearly every operation.

Source