esc
esc copied to clipboard
pulumi
Ability to store values in ESC via a Pulumi programs
Use case:
I am setting up what I call "delivery" roles with Pulumi in AWS that creates an OIDC role.
I want to be able to reference that role programmatically, but I also want to store the name of that role in ESC in the relevant environment with a Pulumi provider.
Will this work with any resource that can be created through Pulumi?
Use case: I create a load of secrets in AWS Secrets Manager and I want them to be available through ESC
What would be the difference between this feature and creating stack outputs then using the pulumi-stacks provider?
is there any information on the timeline for this?
in my case i‘m creating secrets via a pulumi program which i need to mount into kubernetes pods. on kubernetes apps are deployed via flux and i use the external-secrets operator.
it would be extremely beneficial if i can store secrets into ESC in this pulumi program and support mounting through the already existing integration of ESC into the external-secrets operator.
currently, i need to revert back using another solution to handle these secrets but such an integration would make the management way easier and streamlined.
What would be the difference between this feature and creating stack outputs then using the pulumi-stacks provider?
~I wondered the same thing.~
@dbeattie71 I have been doing a little testing over the weekend, and it seems that the token that opens the environment with the pulumi-stacks provider inside also requires read access to the stack. By giving read access to the stack, you also give full read access to any other secrets on outputs and crucially secrets in state.
I think being able to push a secret into an env will create a much-needed mechanism to pass values from a stack that is highly privileged and one that has a less privileged set of actions.
My current use case is a project that manages Auth0 global tenant settings, including connections from our Okta IdP (including credentials for the Okta API). Using ESC's environment variables, it is possible to prevent the API credentials from ending up in state, but there are other client credentials and secrets produced that do end up in state and need to have restricted access while others are fine to be on outputs but really need to be passed via an ESC environment assigned to the platform team to configure clients and API configurations downstream.
We shipped this recently
Launch Blogpost: https://www.pulumi.com/blog/esc-automation-api-pulumi-service-provider-launch/ Documentation:
- https://www.pulumi.com/registry/packages/pulumiservice/api-docs/environment/
- https://www.pulumi.com/registry/packages/pulumiservice/api-docs/environmentversiontag/
- https://www.pulumi.com/registry/packages/pulumiservice/api-docs/teamenvironmentpermission/
