Hey all. I had a situation that I can't figure out currently. I'm trying to create a policy to review AWS S3 buckets. I want to guarantee that a bucket always has a matching BucketPublicAccessBlock resource with that bucket associated with it. It's important that it not use stack validation, but resource validation (Don't want the buckets created without the proper policies). I figured you could use validateResourceOfType and then compare it with the other resource to see if they both exist. However, I haven't been able to find a way to compare 2 different resources. Kind of an "and" condition policy. Any ideas from the community?

What's is resource validation (and stack validation)?

@little-cartoon-10569 https://www.pulumi.com/docs/guides/crossguard/core-concepts/ is what i'm referring to. ComponentResource is a useful function but the goal is to also prevent anyone from "going rogue" and deploying poorly configured resources.

Ah yes. I'm not too familiar with Pulumi Policies, I've used them only on one project. Sorry, I don't know!

@careful-family-14644 I have some ideas, but let me dig into this a bit and I’ll let you know what I find.

That would be awesome! Thank you @witty-candle-66007

@careful-family-14644 Here is some example code. https://github.com/MitchellGerdisch/pulumi-work/tree/master/ts-policy-validate-resource-relationship Read the README and comments in the code to get the full picture. But, one does need to use

validateStack

for this use-case since that’s the only way to have access to all the resources in the stack at a given time. Stack validation does run predeployment but you are limited to what properties you can see. And as you’ll see in example code, this leads to another policy being needed to ensure that works during predeployment.

@witty-candle-66007 Thank you so much for this. Going to test this in a few. However, based on what I know about "validateStack" is that if you do

pulumi up

it will still create the objects and then show the violations. That's somewhat what I'm worried about at this point.

That’s not the case. The policy validation will occur for “validateStack” AND “validateResource” during preview regardless if that’s

pulumi preview

or the first part of a

pulumi up

and both types of policies will also run after the

pulumi up

completes. So your goal of checking before deployment will work here. In fact, if you test the provided code and change the

enforcementLevel

to

mandatory

for the policies and do a

pulumi up

you’ll see that you won’t be allowed to do the actual deployment step if there’s a policy violation.

@witty-candle-66007 Did some testing here and things are looking really good. Still doing a bit of testing. Such as adding and removing and preventative measures. I think we can absolutely make this work. I really appreciate all your help with this.

can you share pulumi code that sneaks through the policy?

@witty-candle-66007 I had copied the most recent version you had committed and changed to mandatory. When using

pulumi preview

I would receive errors as expected. But using

pulumi up --yes --skip-preview --policy-pacy ../policies

in order to automate the process, the warnings show up but only after the stack is created.

Yes. So, yeah,

--skip-preview

throws a wrench into things.

@witty-candle-66007 Hey! I didn't realize who I was talking to this whole time.

🙂 What would you think of a feature in the service that disables the ability to use

--skip-preview

as a way of addressing this use-case? (I’m thinking of opening a github issue for this.)

Definitely a good idea. The intention is to definitely prevent folks from making mistakes with their configurations, this definitely needs to be a function. I know my S3 bucket use case is likely going to be moot next month, but I'm sure there's 10000 other use cases that this will apply to.