Buildkit: Proposal: entitlements

[tonistiigi]

There is an effort going on at https://github.com/moby/libentitlement to clarify ways the user can extend and limit the capabilities of containers. BuildKit should integrate with this process.

That library defines a list of permissions https://github.com/moby/moby/issues/32801 and provides an implementation for using the provided list to generate an OCI spec and an AppArmor profile.

Integration with BuildKit

LLB ExecOp should contain a list of entitlements that should be applied when the process runs. Ideally, this could be metadata info (but can be discussed more when implementing).

LLB BuildOp should contain a list of entitlements that the child ExecOps are allowed to use. An error is produced if inner ExecOps require entitlements outside of that list.

With every build requests user also sends a whitelist of entitlements. This whitelist is supposed to be provided by the user and not the LLB generator or pulled image. This is the way user controls how much privileges the build can request.

The daemon may apply additional limitations. See #237

When invoking a buildctl build command user can provide a list of entitlements the build can use. For example buildctl build --entitlements=security.unconfined. This doesn't mean that the build runs without security restrictions but that the ExecOp part of the build can request to run without restrictions. The entitlements that are considered secure, eg security.confined, network.none are enabled automatically by buildctl.

@n4ss @tiborvass

[tonistiigi]

from https://github.com/moby/buildkit/issues/345#issuecomment-383232999

We can also start with something simple if full libentitlement is too complicated or not fully ready yet. We can implement the basics like security.unconfined security.confined and network.none and don't need to use libentitlement for that. Just make sure it is future compatible.

[kunalkushwaha]

I have few things to discuss before proceeding.

1. the libentitlement project seems not been actively worked after POC demo. So is it okay to use this for buildkit project?

   • We can create an interface with methods similar to functions in libentitlement.go and as suggested in above comment, implement only basics.
   • But in case its stable, we can directly use it. (With interface, so in future can be replaced by other implementation)

2. What entitlements will be using to achieve restrictions (in case implemented within buildkit)?

   • My understanding is its mix of Capabilities, Seccomp & MAC(AppArmor or SELinux).
   • Implementing with all, may require some expert inputs as understanding of each profile and expectation required fair understanding of security

3. For containerd workers, do we need any support from containerd project to support these entitlements?

// cc: @tonistiigi @n4ss @AkihiroSuda

[tonistiigi]

I'm ok with not using libentitlement until that project has a clear roadmap. But lets make sure API is compatible.

We can create an interface with methods similar to functions in libentitlement.go

I don't think we need to be even that complicated if we just start with security.confined, security.unconfined, network.none.

I think lets just add a entitlements array to pb.Op and llb.Constraints and make sure they can be set on Run() methods and validate them when vertexes are loaded in llbsolver.Load().

If validation passes then just pass the data straight to executor. We can have a helper function that takes oci-spec and entitlements and modifies it to these three options so there is no duplicate code for oci and containerd worker.

What entitlements will be using to achieve restrictions

security.confined is the current configuration (we need to fix the host networking issue separately). With apparmor , seccomp, capability restrictions and masked paths.

security.unconfined is similar to --privileged. No extra security controls and some readonly filesystems are readwrite now.

network.none removes the network namespace in executor

For containerd workers, do we need any support from containerd project to support these entitlements?

We should not. They should be all configurable from the spec we send to containerd.

[tonistiigi]

I think this can be closed now. Thanks @kunalkushwaha @smira