Community Meeting April 24, 2024

[lcarva]

Overview
At 10am Eastern, 7am Pacific, 2pm UTC; find your time

Video call link: https://meet.google.com/ved-ivnv-aen
dial-in: (US) +1 409-444-2447‬
PIN: ‪873 550 579#‬
More phone numbers: tel.meet/ved-ivnv-aen?pin=7872592963542&hs=1

Add topics you'd like to discuss below!

[lcarva]

Let's chat about enterprise-contract/ec-cli#1554.

[lcarva]

Notes on the discussion for enterprise-contract/ec-cli#1554:

• @simonbaird, it makes sense to implement the proposal from the issue as is. This is, after all, the behavior we had intended. But there's a larger question about builtins rules and whether or not those should be excludable.
• @robnester-rh, the policy as written adds a source group. If nothing from the source group is being executed, the intent of the policy is missed.
• @lcarva, what if there are multiple source group and one of them resolves to policy rules, but another doesn't? That should likely be an error.
• @simonbaird, there could be corner cases where a blank exception, for example, is granted. And maybe we can have a --allow-zero-rules-from-source flag (or some other name) to make that permitted.
• @robnester-rh, if any source group produces zero rules, it should be an error.
• @lcarva, to clarify, the zero-rules check apply to whether there are no defined policy rules (already done) or if there are no results once exclusions have been applied.

Overall agreement with the discussion above

• @zregvart, let's widen the discussion. We probably want to have bultins as a source group.

I didn't capture the details, but we seem to be onboard with the approach of re-implementing the builtin rules as rego embedded in ec-cli, and have a mechanism to inject them as a source group. (Inject if not already included in the policy, of course.)

[simonbaird]

More notes on the "if it's a policy then it is rego" idea:

The bigger idea:

• We've talked before about moving the "builtin" signature checks, currently written in go, out of ec-cli entirely and defining them in rego, with the help of the custom opa functions we created for doing sigstore operations in rego.
• This would mean ec validate image and ec validate input become more similar to each other, since the "builtin" checks can be removed from ec-cli.
• Taking that one step further, the other thing that ec-cli does before handing off to the rego evaluator is prepare and shape the input. It's not hard to imagine fetching the attestation (and other) input data directly in rego as well. At that point ec validate image could pretty much be replaced entirely with ec validate input where the input is just a list of image refs.
• This seems like a neat idea and we generally like it, however:
  ** It's hard to transition towards that incrementally
  ** We might still want to provide ec validate image with guaranteed sig checks that the user can't mess up

The new idea: As a way to move towards the big idea gradually, and preserve the benefits of providing ec validate image we could do the following:

• Convert the image sig checks and att sig checks to rego (same as we said above), but...
• We compile ec with that rego embedded into it, and include it like another policy source in the policy dir where rego rules exposed are the rego evaluator.

This means we're moving towards "all policies are rego", but in a less disruptive way. We can still call them "builtins" and always include them, but we're just maintaining them as rego instead of plain golang.

Other benefits:

• Less hacky collating of the ec output for the builtin rules.
• Less hacky generation of docs for the builtin rules.
• The possibility to exclude the builtin rules (if we think we want to allow that)
• A sig check failure could maybe not interrupt ec so other valid checks could proceed, e.g. container labels
• We enable further exploration of ec validate input with sig and attestation checks (since it can use the same rego)
• We (maybe) enable the possibility of a "fat" build of ec that has all the rules from the ec-policies repo compiled into it.