Excellent. Is the intention for the analysers to be exposed via the same programming model?

And will it have the ability to retrospectively inspect conformance with a new or modified policy?

Those are great questions. 🙂 @big-piano-35669 or @white-balloon-205 probably have better insight there.

(FWIW, it turns out we do have one example analyzer in the

pulumi/pulumi

repo, though I'm not sure of its precise status: https://github.com/pulumi/pulumi/blob/master/examples/analyzers/infosec/main.go)

Interesting. It’s a bit unclear what additional context each analyzer has access to there. Often they’d need implementing in terms of the entire dependency graph?

Hm, that's an interesting complication. One consequence of the Pulumi model is that the graph is built and executed incrementally, so the complete graph is (generally speaking) not known until the preview/update has completed.

Yes, that seems to be the major difference between Pulumi and Terraform when it comes to execution - TF has a complete graph before execution.

To be a bit more precise, given a resource

r

, we are guaranteed to have seen the transitive closure of `r`'s dependencies by the time

r

is registered, but we are also guaranteed not to have seen any resource that depend on

r

.

Correct.

I think that is OK for the purposes of policy

But perhaps not

It might only be possible to evaluate some policies retrospectively

Which I think might also be OK

Yeah, if a policy requires an understanding of which resources depend on a given resource, then that policy can only be evaluated in retrospect

Though we can give a conservative answer on such a policy using the graph produced by a preview

My canonical example is “instances may not be placed in a subnet with a route to an internet gateway”

....that's a really good example

In that case the instance would have a dependency on the subnet, but the route would be an edge from the subnet also.

esp. as it can be phrased from different perspectives

Assuming we are walking in parallel, there is a possibility the context necessary for matching the policy wouldn’t exist at the evaluation of the instance.

Right. So you might need to implement this policy in such a way that it can handle all possible partial orderings of resource creation that create the problematic result

I wonder if a policy could be made into a graph node such that the execution is delayed until all of the inputs are reified

That could get awkward thoguh

It might be worth adding some library functions to either

pulumi

or perhaps a new

network

package which has things like

cidr_subnet

in order to implement things like “extend this CIDR prefix by n bytes and then find the network number x within it”

(similar to the Terraform

cidr_subnet

interpolation function)

That's a good idea. Would you mind filing an issue for that in https://github.com/pulumi/pulumi?

Done https://github.com/pulumi/pulumi/issues/1552

Thanks!

Late to the party, sorry!

Is the intention for the analysers to be exposed via the same programming model?

Analyzers are gRPC plugins too, so yes, they can be written in any language and have access to the parts of graph available per Pat's comments. The current state is a little half-baked -- which is why we don't advertise or doc them -- but it's a preview of core capability we're going to go pretty hard on in the weeks to come. For instance, we have a query language prototype that will expand to give you GraphQL-ish capabilities to perform rich analysis against resource graphs/plans. I expect we'll have lots more to say about this over the next couple milestones, but for now, if you end up wanting to kick the tires on what's there, just let us know and we can point you at some defaults.

I must say that I’m very excited with Pulumi and impressed as well. I’ve been using Terraform quite extensively, and I really love Terraform and all that it has given me. However, what I’ve always wanted is to be able to write Terraform code in a real programming language. ❤️