quick question about the state file in pulumi ... IIUC it's encrypted ... would it be OK to store it in a git repo?

The state file? Are you using a file state backend? My knowledge may be slightly outdated about file state backend. In any case, it depends. Some output properties are automatically tracked as secrets and are encrypted in your state file. You can also mark something as secret in your program using the resource option

additionalSecretOuts

(I think?) So you could potentially end up with a state file that has a sensitive output property that isn't encrypted unless you mark it as such. The state file as a whole, though, is only gzip'd and not encrypted. You may encrypt it yourself, for eg. using gpg or some other method, but you'd have to decrypt it before Pulumi can read it, of course.

Given that the state file is the product of a successful execution of the Pulumi code, a more suitable shared location might be an artifact repository. However, there's already file-like backends that offer shared location and support fine-grained access control (e.g. S3), so that would be a better option than git.

I am totally new to pulumi so I might be totally looking at it from the wrong direction. Just heard that the state is encrypted and so I thought "yay!". What backends are most popular? If encrypted, S3 certainly could be a good option. I don't like that this is yet another auth to maintain though. From that aspect relying just on the git auth would have been nice.

Curious why you are wanting to manage the state yourself and not use Pulumi Cloud?

If you deploy to one of the big three clouds, putting the state into a bucket there has minimal auth overhead, because you need to authenticate with the cloud anyway to be able to provision infrastructure there. You'll also get encryption of the state file "for free". (The S3 backend option also works with other S3-compatible blob stores like Minio.)

Either it's client side encryption or it's not worth mentioning IMO. And S3 only offers server side encryption. We are not really using any of the big 3 clouds. Well, other than S3 (but with client side encryption). So it really is another auth. I guess in a GitOps setups it's not that terrible. And of course we could encrypt/decrypt manually - but it's just more moving parts. If the state file is client side encrypted we would consider Pulumi Cloud - hence the question.

> S3 only offers server side encryption That's strictly speaking not correct. S3 offers various flavors of SSE (differentiated by who's owning and managing the key) as well as client-side encryption. But I don't think Pulumi supports "native" client-side encryption as promoted by AWS. > If the state file is client side encrypted we would consider Pulumi Cloud - hence the question. Have a look this blog post that walks through the process of encrypting sensitive data in the state file.

I read that section as "you are on your own", but it seems like the aws client does support client side encryption (now) https://docs.aws.amazon.com/AmazonS3/latest/userguide/UsingClientSideEncryption.html So it's just a matter of using it. I wasn't aware. If pulumi does not support it, we are back to my question. I'll have a read on the article you linked. Thanks!

I read that section as "you are on your own", but it seems like the aws client does support client side encryption (now)

I think you are correct that you're on your own in the situation you're dealing with. The client is "just" a client-library that handles encryption as well as the S3 interactions, you can also use any other means of encryption or create your own client by combining an AWS SDK with an encryption library. After all, from S3's perspective, it doesn't matter whether the files you send are encrypted or not. It will add its own encryption anyway.

If pulumi does not support it, we are back to my question.

Pulumi uses https://pkg.go.dev/gocloud.dev/blob/s3blob for the S3 backend (per https://github.com/pulumi/pulumi/blob/master/pkg/backend/diy/backend.go#L39C5-L39C28), which as far as I can tell doesn't support "transparent" client-side encryption. If the encryption within the state file is not sufficient for you, you'll probably have to point Pulumi to a locally mounted encrypted volume, which you can then store and share. I'd be interested in hearing what solution you eventually go with.