Policy remediations SDK support #314
Conversation
This renames transforms to remediations in the Node.js SDK. It also accomplishes the new design where a single policy can define both logic to validate policy conformance *and* to remediate, based on the enforcement level chosen. Python equivalent incoming.
This renames transforms to remediations, while also adopting the new style of expressing remediations as an attribute of a policy.
|
@justinvp This is fairly close. Probably good time to take an early look. I am mostly writing tests at this point. |
There was a problem hiding this comment.
What are we going to do about secrets? I haven’t tried it, but it looks like we’re going to lose those in a remediation, because when we deserialize the incoming properties here in the policy SDK, we strip the secretness of values, and then when we return the resulting properties, any secrets that were present will no longer be present going out. Perhaps we need a proxy object that can keep track of secrets?
Separate from that, we may also want to provide a way for a remediation to introduce a new value that’s a secret. Maybe we could allow users to use pulumi.secret/Output.secret from the core SDKs, and update the serialization code here to support serializing such outputs?
That is one of the few things not done just yet, but that I'll be completing over the weekend. I called out the approach in the design doc -- see "Dealing with Secrets". The idea was to automatically re-apply secret-ness to anything that was a secret prior to calling the remediation. This feels like it is the least surprising and does the right thing by default. I had not considered a new proxy that can keep track of secrets ... That may be another approach to accomplish the same, although we'd need a change at the gRPC layer to send the secrets over to the analyzer instead of plaintexting them. The nice thing about the engine doing this is a remediation can in fact just remediate a property like usual, even if it is secret, and the engine will just re-apply the secret-ness back on the engine side of the call. That said, I do like your idea of being about to use What do you think about this approach? |
Yeah, I had that in mind as well. I think it's reasonable. One thing I'm curious about: Will deeply nested secrets be preserved or will the entire top-level property be made a secret when re-applying secret-ness back on the engine side of the call if the property had originally contained a secret? The reason I ask is because users are often frustrated when a secret in a nested array or map ends up "tainting" the entire property as a secret (because it can make diffs difficult to reason about). They don't want to see the whole property being a secret, they want the one secret value nested within a array/map to show as a secret, and not any other items that aren't secrets.
Note: we already keep secrets when sending properties to the analyzer, and it looks like the current implementation in your PR does for They're stripped in the deserialization code in the policy SDK: pulumi-policy/sdk/nodejs/policy/deserialize.ts Lines 106 to 107 in 1f97d95 pulumi-policy/sdk/python/lib/pulumi_policy/deserialize.py Lines 57 to 60 in 1f97d95 |
This change preserves secrets round-tripping through policy remediations. This is the Node.js side of the change, and Python will come shortly. This works by preserving the secret nature of secrets as they are read from property state. All values are proxied, however, so that they can still be used as plain values. The proxying will trap all writes to objects and ensure that secretness is preserved on all properties that were secret on their way in to the remediation. The serialization code then detects and preserves secret values as state is returned from a remediation.
|
The proxying approach worked quite well and it's easier to make it perfectly granular. I just pushed the changes. I explored just using For now, I'll just go with the current approach as it at least does the job of preserving secrets. Feedback welcome! |
Co-authored-by: Justin Van Patten <jvp@justinvp.com>
Depend on `@pulumi/pulumi` `^3.88.0`. Update other deps to match `@pulumi/pulumi`.
pulumi>=3.88.0 and update other deps to match the pulumi package
This PR implements the TypeScript and Python policy SDK side of support for the new policy remediations feature. This lets developers implement new remediations callbacks, similar to policies, in their policy packs. See pulumi/pulumi#14080 for the engine/CLI support, which is a prerequisite for this working.
Note: This change depends on pulumi/pulumi#14080 and certain tests will fail until released.