The company where I work (strictly regulated/audited environment) is yet to embrace containers but would like to adopt them for some applications. There is the view that as the image build process issues commands as root (or could be overridden by the user by use of the USER command), that building (not running) a container is effectively giving a user unfettered access as root during the build process. This is anathema to them and goes against all manner of company policies. Access to certain commands for computers is restricted via PowerBroker, i.e. access to certain commands requires explicit permissioning and is logged/subject to audit.

We need to allow container images to be built by a CI/CD system as well as ideally to allow developers to be able to build containers locally. Containers will generally be run in Kubernetes, but may be run directly on a VM. I'd like to be able to have CI build agents spin up on demand, as there are a lot of developers, so I want to run the build process within Kubernetes.

What is the best practice for building docker containers in this sort of environment please? Should we look to restrict access to commands within the Dockerfile?

My current thinking for this approach:

CI/CD:

1. Define "company-approved" image to act as build agent within Kubernetes.
2. Build image defines a user that the build process runs as (not root).
3. Build agent image contains PowerBroker, enabling locking down access to sensitive commands.
4. Scan docker file for use of user command and forbid this.
5. Build agent runs docker-in-docker, as per here (https://applatix.com/case-docker-docker-kubernetes-part-2/). This achieves isolation between multiple build instances whilst ensuring all containers are controlled via Kubernetes.
6. Images are scanned for security compliance via OpenSCAP or similar. Passing the scan is part of the build process. Passing the scan allows the image to be tagged as compliant and pushed to a registry.

I'm uncomfortable with the thinking around (4), as this seems a bit rule bound (i.e. it's a sort of blacklist approach) and I'm sure there must be a better way.

Developer's localhost:

1. Define "company-approved" base images (tagged as such inside a trusted registry).
2. Image defines a user that the build process runs as (not root).
3. Base image contains PowerBroker, enabling locking down access to sensitive commands.
4. Create wrapper script on localhost that wraps docker build. No direct access to docker build: user must use script instead. Access to script is secured via PowerBroker. Script can also scan docker file for use of user command and forbid this.
5. Pushing of images to registry requires tagging which requires scanning for security compliance via OpenSCAP or similar as above.

I'd like to use the OpenSCAP results plus the CI system to create an audit trail of the images that exist; similarly for the deploy process. The security team that monitor for CVEs etc should be able to understand what containers exist and have been deployed and be able to trigger rebuilds of images to make use of updated libraries, or to flag up to developers when containers need to be rebuilt/redeployed. I want to be able to demonstrate that all containers meet a security configuration policy that is itself defined as code.

Is this a sensible way to go? Is there even a risk for allowing a user to build (but not run) a container image without restriction? If there is not, what's the best way to ensure that a foolish/malicious developer has not undone the best practices inside the "approved base image", other than a manual code review (which is going to be done anyway, but might miss something)?

By the way, you must assume that all code/images are hosted in-house/on-premises, i.e. nothing is allowed to use a cloud-based product/service.