I have a question about the deployments feature - is it, or will it be possible to set up with Open ID Connect, to avoid storing any permanent credentials for the deployment? Another approach I was thinking of is to have something deployed in the cloud provider that pushes out new credentials to Pulumi service at regular intervals, although I am not sure if that is possible to do?

Hi Erik! For the second point, we are planning to expose APIs to allow updating environment variables for a stack to allow credential rotation: here's the issue: https://github.com/pulumi/service-requests/issues/141 would be awesome if you could comment and upvote. For the first point, we would love for you to open an issue about OIDC support - I definitely see the desire for something like this and having an open issue where folks can express interest will help us prioritize. You can do that here: https://github.com/pulumi/service-requests/issues/new

@quaint-hydrogen-7228 how are you triggering deployments, via git?

@lemon-agent-27707 Yes, in some cases. As we are working with multiple clients and solutions it varies a bit. In general we are transitioning to temporary credentials overall, with end user credentials (for AWS) handled through AWS IAM Identity Center (AWS SSO), and service-oriented executions either running inside AWS with IAM roles, or for access from outside (e.g. GitHub) the aim is to use temporary credentials in some way. Currently there are a number of flows which use AWS CDK + CDK Pipelines and run inside AWS, other flows may be manual or use Github Actions, Bitbucket Pipelines. Both Github and Bitbucket have OIDC support, so flows with permanent credentials set up will likely be switching to OIDC there. I would like to use Pulumi for some shared infrastructure/platform solutions, which are either CodePipeline or manual at the moment. Trigger deployment via Git directly is ok, as long as there can be an approval/review step in the workflow.

Thanks for the explanation. If you are manually triggering deployments, another option is to call the REST API directly. This allows you to provide environment variables that are scoped just for that deployment, which might work better for your current model. We are working on adding public APIs to configure environment variables for click to deploy and git push to deploy in the service console. We do have existing APIs that do this, but they aren't documented and they could change. Up to you if you want to use them given that these ones don't have stability guarantees:

/console/stacks/{orgName}/{projectName}/{stackName}/deployment/settings/environment
{
  "name": "...",
  "value": "...",
  "encrypt": true
}

Thanks for the reply! The REST API could absolutely be an option for manual deployments, good point. I will have to play around with that. Right now I think it is enough to know that these features are in the pipeline, not necessary to work with unstable APIs.