Rego source policy additional UX

[tonistiigi]

This issue is to discuss UX changes for #3539 for additional control and helpers.

Build

build and bake automatically load a default policy file based on the Dockerfile path(if one exists):

Dockerfile        → Dockerfile.rego
foo.Dockerfile    → foo.Dockerfile.rego

When building from a remote context, these files are also loaded from a remote context, like the Dockerfile.

Users may override or extend this behavior using:

--policy [csv] [--policy [csv]]...

Available options

filename=<path>

Add a policy file. Can be combined with reset.

reset=<bool>

If set, the currently loaded policy (eg. the default based on Dockerfile) is ignored and the policy set is replaced.
After reset=true, only explicitly provided filename= entries are used.

disabled=<bool>

Disable policy evaluation entirely. Using this together with other policy flags is an error.

strict=<bool>

Require policy enforcement.
If true, builds fail when running against a BuildKit that does not support policies.
Policy file load or compile errors always fail regardless of this setting.
Initially, this will default to false but may change somewhere in the future where BuildKit instances without policy support become a rarity.

log-level=<level>

Set policy logging verbosity (e.g., debug).

---

Optional / Under Consideration

ignore=<expr>

Example:

--policy ignore=image.repo=alpine

Potential mechanism for skipping specific sources when generating the policy input.
Not sure if we need smth. like this.

---

Policy Subcommand

These commands help writing policies and ensuring that they continue to work correctly after code changes.

buildx policy print-schema

Print the JSON schema describing the policy input object.

buildx policy test <path>

Execute a _test.rego file with fixed inputs, similar to opa test.
Inputs are not fetched via BuildKit, but part of the test already.

buildx policy eval --filename=<name> [--print] [source]

Evaluate the specified policy against the input for source.

• These are the same source values as can be specified in --build-context.
  The source is resolved in BuildKit and then checked against the policy definition.

• If --print is set, the policy isn’t evaluated; the input object is printed instead.
  Useful for exploring and validating values that policies are written against or for capturing input definitions for tests.

• If source is not specified, the command expects an input object JSON on stdin.

@crazy-max @dvdksn @AkihiroSuda @colinhemmings

[crazy-max]

build and bake automatically load a default policy file based on the Dockerfile path(if one exists):

Dockerfile        → Dockerfile.rego
foo.Dockerfile    → foo.Dockerfile.rego

When building from a remote context, these files are also loaded from a remote context, like the Dockerfile.

I like it, this is a predictable convention and will "just work" for most users. The strict "next to Dockerfile only" behavior is simpler and probably best.

For bake I wonder if we could have something similar to dockerfile-inline like:

target "default" {
	dockerfile-inline = <<EOT
FROM alpine:latest
RUN echo hello
EOT
	policy-inline = <<EOT
package docker
default allow := false
allow if input.local
allow if {
    input.image.hasProvenance
}
decision := {"allow": allow}
EOT
}

Btw could we also have the bake equivalent like docker-bake.rego that would be applied to all targets? If a target already has a policy then it would be merged.

filename=<path>

Add a policy file. Can be combined with reset.

A bit verbose, I think file would be better to be consistent with build or bake commands UX with --file?

reset=<bool>

If set, the currently loaded policy (eg. the default based on Dockerfile) is ignored and the policy set is replaced. After reset=true, only explicitly provided filename= entries are used.

I'm not sure about this attribute. Could we have instead an operator to append or override similar to --set with bake?:

# append foo.repo (or add if no default found)
--policy filename+=foo.rego
# override with foo.rego (or add if no default found)
--policy filename=foo.rego
# override with foo.rego and append bar.rego
--policy filename=foo.rego filename+=bar.rego

strict=<bool>

Require policy enforcement. If true, builds fail when running against a BuildKit that does not support policies. Policy file load or compile errors always fail regardless of this setting. Initially, this will default to false but may change somewhere in the future where BuildKit instances without policy support become a rarity.

Not directly related but I see a use case where orgs would want to enforce policies globally. I guess this would be some configuration on daemon side?

ignore=<expr>

Example:

--policy ignore=image.repo=alpine

Potential mechanism for skipping specific sources when generating the policy input. Not sure if we need smth. like this.

Looks reasonable to leave this out for first iteration and revisit once there is a real-world demand. The expression syntax at the CLI level can be a bit tricky.

Policy Subcommand

I like the mirroring of OPA tooling, which will be familiar to policy authors, specially for testing: https://www.openpolicyagent.org/docs/policy-testing

[tonistiigi]

Btw could we also have the bake equivalent like docker-bake.rego that would be applied to all targets? If a target already has a policy then it would be merged.

Policies associated with Dockerfile are loaded automatically in bake, and there should be a key to match build --policy. If want to use same policy across Dockerfiles then that can be done with normal bake target sharing.

A bit verbose, I think file would be better to be consistent with build or bake commands UX with --file?

👍

I'm not sure about this attribute. Could we have instead an operator to append or override similar to --set with bake?:

That would only reset the filename though. While reset resets everything.

[crazy-max]

That would only reset the filename though. While reset resets everything.

When you say "resets everything" you mean filenames and default rego attached to Dockerfile? If so I think my suggestion still works:

# set foo.rego (override default one if available)
--policy filename=foo.rego