Accept secrets

[iwahbe]

Hello!

• Vote on this issue by adding a 👍 reaction
• If you want to implement this feature, comment to let us know (we'll work with you on design, scheduling, etc.)

Issue details

Customizations such as pulumi/pulumi-gcp#1316 require knowing what input fields are secret. To enable these kinds of customizations, we should support secrets in the bridge.

This is a prerequisite for implementing other secret strategies in the bridge, such as secret-by-value.

Affected area/feature

[t0yv0]

This affects AWS as well and is fairly convoluted at the moment. I would request a design doc on this (can collab).

This is a prerequisite for other secret strategies, such as secret-by-value.

Not obviously true.

[iwahbe]

This affects AWS as well and is fairly convoluted at the moment. I would request a design doc on this (can collab).

I'd be happy to work with you on a design doc. This isn't a proposal, as much as a placeholder for one.

This is a prerequisite for other secret strategies, such as secret-by-value.

Not obviously true.

It is a prerequisite other strategies, when implemented in the bridge. The engine could implement these without the bridge supporting secrets.

[t0yv0]

Awesome. Let's do a design here to consider a few options where we can go, also cover AWS issues and issues with secrets in Invoke and Configure.

[t0yv0]

#1621 worth picking up soon-ish? I think this makes sense long-term for completeness but can be a bit time-consuming to thoroughly test. For now relying on the engine to discover and re-inject secrets continues to work mostly OK, and with pulumi/pulumi#15032 we can simplify this a fair bit which brings us to the better place.

[t0yv0]

Linking the related issues with AWS tagsAll causing pressure on bulk-encryption in pulumi/pulumi#15498

[iwahbe]

Related to pulumi/pulumi#17440 (comment).