Conversation
docker-compatible container build --secret id=aws,... for RUN --mount=type=secret
|
I haven't done much Swift before, so watch out for any stupid mistakes I may have made. One design caveat: I passed secrets by copying the build-args code, because they're functionally the same. But, systems are supposed to take care that the secret values aren't logged or stored anywhere, so HTTP headers are a much riskier way to send them than transporting them separately in a new BuildTransfer. I nevertheless used the headers to send the secrets because 1. it seemed easier 2. I didn't notice anything that would log or record these headers 3. it looked like the headers and BuildTransfers alike are just data sent through gRPC, so, not much practical difference right now. |
| let data: Data | ||
| if parts.count == 1 || parts[1].hasPrefix("env=") { | ||
| let env = parts.count == 1 ? key : String(parts[1].dropFirst(4)) | ||
| guard let ptr = getenv(env) else { |
There was a problem hiding this comment.
Nit comment.
We can avoid using unsafe pointer and strlen by
guard let value = ProcessInfo.processInfo.environmentenv] else {
throw ContainerizationError(.invalidArgument, message: "secret env var doesn't exist \(env)")
}
data = Data(value.utf8)
There was a problem hiding this comment.
I couldn't find documentation on how ProcessInfo.processInfo.environment would behave on environment variables containing non-UTF8 data, so I went with C getenv. Is there a better Swift way of getting env vars as Data without going through UTF8?
Alternatively, just using ProcessInfo.processInfo.environment and accepting whatever limitations that places on non-UTF8 env var values could just be fine, given that env vars needing to be \x00-free already makes it iffy to use env vars on non-text data secrets. Would this be preferred here?
| } | ||
|
|
||
| var secretsData: [String: Data] = [:] | ||
| for secret in self.secret { |
There was a problem hiding this comment.
Could we move this part under validate function? #1273 as an example.
There was a problem hiding this comment.
Moved it. Let me know if I did what you were expecting.
2 participants
docker-compatible
--secret id=key,...arg forcontainer build, that works with Dockerfiles withRUN --mount=type=secretRequires apple/container-builder-shim#69
Type of Change
Motivation and Context
Adds support for Dockerfiles that use build secrets (e.g.
RUN --mount=type=secret ...)Testing