Create a resource in kubernetes domain

[meganwolf0]

Is your feature request related to a problem? Please describe.

Looking at the pepr (or kyverno, gatekeeper, etc) validations, it would be useful to create a dummy resource to test policy enforcement then measure the outcome (ideally denied if some policy you're testing is implemented correctly). Wondering if this feature might have other use cases - thinking along the lines of probing networking and/or making api requests.

This might also have some baggage associated - because you're not really fully providing "direct proof" via explicit manifest data, you're doing like a proof by non-occurrence - e.g., if a resource is blocked, then the policy is working. That's maybe something that could be interesting to capture as different Lula workflows or reporting?

Describe the solution you'd like

• Given a policy is enacted in the cluster
• When a Lula validation wants to validate the policy
• Then a dummy resource could be created

Describe alternatives you've considered

None

Additional context

None

[brandtkeller]

I agree with the intent of the problem statement. Having a way to "challenge" that something is both configured properly AND operating as expected is what the project should continue to develop.

I do want to challenge/discuss what this means for Lula runtime. This sounds like a tipping-point for needing to establish and document guardrails for what is required. Optimally what Lula performs is read-only - allowing for the portability of validations to not perform a write-operations unintentionally.

that said - I do see value here and there are other scenarios where I have wanted to enable "executing" some process for the purpose of collecting the output for validation. Is there a possibility that we can explicitly define a validation is "executable" (via a flag?) which requires explicit opt-in? Something to help provide guardrails such that Lula isn't used for malicious purposes for which we can help control.

[meganwolf0]

@brandtkeller all good points - yeah I do agree that this does feel a little extra and possibly an inflection point for Lula. I would maybe offer the counterargument that what Lula is able to do in a cluster could(/should?) be a function of the RBAC roles defined for Lula. I think it's probably important to document that you should never be running Lula on a prod cluster with like an Admin kubeconfig - I would hope that's already obvious to any users haha. I think this might also be venturing into a realm that looks more like sonobuoy, which seems like an acceptable tool used to do these kinds of cluster-write ops for testing.

For the cases where this is simply run in a pipeline, does it matter if Lula adds/mutates resources in the cluster if it's executing at the end of the pipeline?

I think at baseline what you said about adding a flag or something specific to call out k8s write things would be beneficial. I'm not entirely sure how this manifests - is it something where there's an additional CLI "is this ok" check when you try to lula x a file that could contain write operations (e.g., kubernetes-spec.create-resources not nil)?

[brandtkeller]

@meganwolf0 agree with the documentation of recommendations for Lula runtime. One of the undocumented assumptions to this point is that domains offer a way to help control what is happening. IE we could have shelled-out to Kubectl but instead wanted explicit control over read operations with the kubernetes domain - it shouldn't be possible to create a resource with the kubernetes resource currently and as such we haven't been too concerned about the read-only vs admin RBAC.

For the cases where this is simply run in a pipeline, does it matter if Lula adds/mutates resources in the cluster if it's executing at the end of the pipeline?

I don't see an issue here - but the workflow shouldn't need to delineate between dev/prod. Optimally these are validations that can be used/re-used across many clusters. This can still be done as described in the issue - but we just have to cover all the bases for how this could potentially impact a production environment.

I think at baseline what you said about adding a flag or something specific to call out k8s write things would be beneficial. I'm not entirely sure how this manifests - is it something where there's an additional CLI "is this ok" check when you try to lula x a file that could contain write operations (e.g., kubernetes-spec.create-resources not nil)?

This would be the part to prototype - something to set the standard as an indicator that the feature being used CAN be used for write operations. I was brainstorming a few examples such as maru-runner/shell domains and the existing API domain which will need this functionality.

[meganwolf0]

This would be the part to prototype - something to set the standard as an indicator that the feature being used CAN be used for write operations. I was brainstorming a few examples such as maru-runner/shell domains and the existing API domain which will need this functionality.

Sounds good - I will include something as a flag to users. I'm kinda thinking it'll be along the lines of what I mentioned above (plus addition of like --confirm flag to skip the verification check, similar to how zarf operates). Or do you have another way you think it should be implemented?

[brandtkeller]

Is the addition of supporting write-operations something that should warrant an ADR? I'm not sure we can get away with not eventually supporting the extensibility for doing something that can potentially modify the environment -> but I do want to emphasize the weight of potential concerns this may raise from personas involved.