provider rotation

[nyobe]

Introduces a new provider type and verb to support rotating static credentials.

Rotator providers have an additional state input which is used as a write-back target. The result of invoking Rotate is persisted back into the environment to this key. This provides a stable location to write to without accidentally clobbering interpolations that might be used for other inputs.

The new fn::rotate function type is used to invoke this new type of provider. It behaves similarly to existing providers during Open, but during rotation the evaluator will invoke the Rotate methods and collect their outputs, which are returned to the caller. The caller is expected to persist these updates back into the environment as a new revision.

# long form
fn::rotate:
  rotator: provider
  inputs:
    # any config the provider needs to use during rotation
  state:
    # persisted state

# short form
fn::rotate::provider:
  inputs:
    # any config the provider needs to use during rotation
  state:
    # persisted state

Closes https://github.com/pulumi/pulumi-service/issues/24986

[pgavlin]

I don't love the short form intermixing state and inputs. I would prefer that the short form just lifts provider from a property to part of the function name and retains both inputs and state as properties. This allows users to write things like:

  commonInputs:
    ...
  foo:
    fn::rotate::provider:
      inputs: ${commonInputs}
      state: ...

I think this is kind of a fundamental issue, FWIW. Even if we store state out-of-band, unless we reference it by path (which kills the ability to refactor via cut-and-paste), we'd need something in the provider inputs that serves as an identifier for the state.

[dschaller]

Just want to check, we are ok if there is no initial state set on the rotator? (This makes sense but I vaguely recall us mentioning that users would set at least current on this when adding a new rotator)

[nyobe]

I think it depends on the Rotator- the schema can be used to enforce it being present or optional. But I think it's also fine to make the key required 🤷‍♀️

[dschaller]

Just for my own knowledge, what does export("") do?

[nyobe]

This is supposed to be the environment name which I think is just used for annotating source ranges?

[pgavlin]

yep that's right

[nyobe]

I don't love the short form intermixing state and inputs. I would prefer that the short form just lifts provider from a property to part of the function name and retains both inputs and state as properties.

Yeah, hoisting the state out of inputs for the short form is a bit cheeky. I've removed it: 53dc66c

[pgavlin]

one nit on naming, but LGTM otherwise

[pgavlin]

yep that's right