https://pulumi.com logo
Join Slack
Powered by
This message was deleted.
# general
s
This message was deleted.
🙏 1
l
What's is resource validation (and stack validation)?
I recommend unit tests for this. Coding policy states that all buckets are created via your ComponentResource, and your ComponentResource has a unit test that confirms your requirements.
c
@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.
l
Ah yes. I'm not too familiar with Pulumi Policies, I've used them only on one project. Sorry, I don't know!
w
@careful-family-14644 I have some ideas, but let me dig into this a bit and I’ll let you know what I find.
c
That would be awesome! Thank you @witty-candle-66007
w
@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.
Let me know if you have any questions.
c
@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.
w
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.
Play with it and I’m happy to hop on a call and dig into things a bit more with you.
BTW, I think I have a simpler example that doesn’t need the 
bucket.bucket
policy. Just need to test it a bit more.
@careful-family-14644 I pushed an updated version of the policy-pack that doesn’t require enforcing the access block reference the bucket using the 
.bucket
property.
c
@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.
@witty-candle-66007 So as I feared, the issue with validateStack is that the poorly configured objects are still created
w
can you share pulumi code that sneaks through the policy?
oh and to make sure it’s not this: In my example code, I set the policies to be 
advisory
which won’t stop the update. But setting the policy to 
mandatory
would prevent the update from occurring.
@careful-family-14644 Curious if you have any additional information on the objects that are still created.
c
@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.
Here's a response from support as well: Regarding CrossGuard policies, they operate on an individual resource level. That means, Resource Validation Policies evaluate the conformance of a resource properties rather than doing a cross resource examination, and this before the deployment happens. That said though, Stack Validation Policies are designed to evaluate conformance across a stack resources but only once the stack has been deployed. The case you describe is a bit of a corner case given the resource 
BucketPublicAccessBlock
as it resides outside of the 
Bucket
resource itself unfortunately.
My assumption is that you're still using preview when performing the 
pulumi up
function?
w
Yes. So, yeah, 
--skip-preview
throws a wrench into things.
c
@witty-candle-66007 Hey! I didn't realize who I was talking to this whole time.
w
🙂 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.)
c
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.
Thanks again for everything!
8 Views
Open in Slack
PreviousNext
Powered by