Description
In a maintainers meeting last Thursday, there was a discussion how to move forward with Build secrets.
The previous PR #30637 is closed atm but we need to make sure that the issue is still tracked. The issue was closed because of design issues(listed below) and possible changes/features coming with #32507. This issue is mainly for keeping the secrets discussion from blocking #32507.
Open questions:
Secret sources:
In #30637 secrets are sent from the client with the context tar. There were concerns if these should be loaded from swarm secrets instead. The use cases seem quite different but it does feel weird to have 2 secrets implementations. Also, the current "build-secrets" use cases are not as secure as swarm ones.
Sending secrets:
In #30637 secrets are injected into context tar on the client side and extracted on daemon before being used. With #32677 this could be done independently from context.
Dockerfile UI:
In #30637 user specifies target path for the secrets in cli command with --build-secret flag. All data exposed like this will become available in /run/secrets for every RUN operation. Normally it is the image/dockerfile author who knows where specific secrets were expected. SECRET Dockerfile command was one of the options considered. #32507 lets image author specify the mount path. With moby/swarmkit#2118 regular swarm secrets do not need to be in /run/secrets either. #32507 allows exposing mounts to a specific command that needs a secret, not to everything at once.
Build cache:
#30637 ignores build cache, #32507 uses it. It is probably more correct to ignore cache to avoid chosen plaintext attacks so #32507 would need to allow that.
Other solutions:
Most examples that show build secrets use it for SSH keys. There are other ways for exposing this specific feature. #32677 allows ssh forwarding(poc tonistiigi@a175773). By exposing git sources as build stages we could use any auth(ssh, oauth) for cloning git repos.
Activity