Values that mint on demand
Addresses that hold nothing and mint a short-lived credential when asked, with lifetime bounds and the live leases listed.
Some addresses in your workspace hold no value at all, and Integrations then Dynamic Engines lists them. Each one asks an upstream system for a credential the moment a job needs one, and that credential expires on its own.
The list
Each row carries:
- the display name, and whether it is turned on
- the lifetime bounds
- the connection behind it
- the count of live leases
- a link to the address it lives at
Turning one on and off happens here. Minting a credential, and taking sessions back, happen on the address itself, under Projects.
The one engine that ships today
| Engine | What it mints |
|---|---|
| AWS STS assumed role | Temporary access key, secret and session token for a role you name |
It accepts an AWS IAM connection or an AWS role connection. A role connection chains, so the connection's own assumed session is the caller rather than anything belonging to penv.
AWS session credentials expire on their own and cannot be revoked one at a time. Revoking sessions for a role affects every live lease on that role.
Adding one
The dialog that adds an address that mints on demand lives on the environment's key list. It asks for the engine and the connection to mint through, then for the address and the configuration that engine needs. Which connections can back it and every lifetime bound come from the engine itself, so the form has nothing hard-coded in it.
The address itself
Opening one of these addresses shows the mint panel rather than a current value, because there is no stored value and no version history. Offering Set New Version for one of these would be the overwrite prompt that penv exists to prevent.
The panel mints a credential and lists live leases with who took each one and when it expires. The engine that ships revokes in bulk only, so no per-lease revoke button is rendered beside a lease. One button takes out every live session on the role.
Taking sessions back
Bulk revocation is two steps, and the first one changes nothing.
Opening the dialog needs dynamic:read. penv composes the deny policy, names the role it belongs on, and counts the sessions it would affect. Nothing is written and nothing is applied.
You attach that policy to the role in your own AWS account. penv writes the policy out and does not apply it, because applying it needs permission to edit your IAM roles and no connection is granted that.
Confirming needs dynamic:revoke and records that you applied it. Only sessions issued before the timestamp the dialog showed you are affected.
Marking the leases revoked before you had applied anything would make the list claim a revocation nobody performed, which is why the confirm step exists at all.
The lease route
An environment can also let a machine mint one over the API rather than through the console. That switch sits on the environment's key list and appears once something in the environment mints on demand.
What each action needs
| Action | Needs | Confirm it is you | Recorded as |
|---|---|---|---|
| Open the engine list | dynamic:read | No | not recorded |
| Add a minting address | dynamic:configure | No | integration.engine_created |
| Turn one on or off | dynamic:configure | No | integration.engine_toggled |
| Remove one | dynamic:configure | No | integration.engine_removed |
| Mint a credential | dynamic:generate | No | integration.lease_issued |
| Open the bulk revoke dialog | dynamic:read | No | not recorded |
| Confirm you applied the policy | dynamic:revoke | No | integration.leases_revoked |
| Change the lease route switch | dynamic:configure | No | integration.lease_api_changed |
Both machine roles carry dynamic:generate, because minting reads a credential rather than changing a stored one. Withholding it is what a custom machine role is for.
Next: browsing the record.