You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
RUN --mount=type=secret,id=TEST_BUILD_SECRET_A,env=TEST_BUILD_SECRET_A echo -n \$TEST_BUILD_SECRET_A | sha256sum > /foo_secret_hash.txt
26
+
RUN --mount=type=secret,id=TEST_BUILD_SECRET_B,dst=/tmp/bar.secret cat /tmp/bar.secret | sha256sum > /bar_secret_hash.txt
27
+
EOF
28
+
cat <<EOF > devcontainer.json
29
+
{
30
+
"build": {
31
+
"dockerfile": "Dockerfile"
32
+
}
33
+
}
34
+
EOF
24
35
```
25
36
26
-
Inspect the Dockerfile and devcontainer.json files in the new directory.
27
-
```bash
28
-
cat devcontainer.json
29
-
cat Dockerfile
30
-
```
31
-
32
-
Note that the Dockerfile requires two secrets: `TEST_BUILD_SECRET_A` and `TEST_BUILD_SECRET_B`. Their values are arbitrarily set to `secret-foo` and `secret-bar` by the command below. Building the container image writes the checksums for these secrets to disk. This illustrates that the secrets can be used in the build to enact side effects without exposing the secrets themselves.
37
+
The Dockerfile requires two secrets: `TEST_BUILD_SECRET_A` and `TEST_BUILD_SECRET_B`. Their values are arbitrarily set to `secret-foo` and `secret-bar` by the command below. Building the container image writes the checksums for these secrets to disk. This illustrates that the secrets can be used in the build to enact side effects without exposing the secrets themselves.
33
38
34
39
Execute the build using this command:
35
40
```bash
@@ -43,21 +48,60 @@ docker run -it --rm \
43
48
```
44
49
45
50
This will result in a shell session inside the built container.
46
-
You can now verify three things:
47
-
* The secrets provided to build are not available once the container is running. They are no longer on disk, nor are they in the process environment, or in `/proc/self/environ`.
51
+
You can now verify two things:
52
+
53
+
Firstly, the secrets provided to build are not available once the container is running. They are no longer on disk, nor are they in the process environment, or in `/proc/self/environ`:
48
54
```bash
49
55
cat /proc/self/environ | tr '\0''\n'
50
56
printenv
51
57
```
52
-
* The secrets were still useful during the build. The following commands show that the secrets had side effects inside the build, without remaining in the image:
Finally, the secrets were still useful during the build. The following commands show that the secrets had side effects inside the build, without remaining in the image:
53
86
```bash
54
87
echo -n "secret-foo"| sha256sum
55
88
cat /foo_secret_hash.txt
56
89
echo -n "secret-bar"| sha256sum
57
90
cat /bar_secret_hash.txt
58
91
```
59
92
60
-
Notice that the first two checksums match and that the last two checksums match.
93
+
Notice that the first two checksums match and that the last two checksums match. Expected output:
@@ -103,10 +147,10 @@ Build secrets are meant for use cases where the secret should not be accessible
103
147
Build secrets are only protected if they are not copied or moved from their location as designated in the `RUN` directive. If a build secret is used, care should be taken to ensure that it is not copied or otherwise persisted into an image layer beyond the control of Envbuilder.
104
148
105
149
### Who should be able to access build secrets, when and where?
106
-
The secure way to use build secrets with Envbuilder is to deny users access to the platform that hosts Envbuilder. Only grant access to the Envbuilder container once it has concluded its build, using a trusted non-platform channel like ssh or the coder agent running inside the container. Once control has been handed to such a runtime container process, Envbuilder will have cleared all secrets that it set from the container.
107
-
108
150
Anyone with sufficient access to attach directly to the container (eg. using `kubectl`), will be able to read build secrets if they attach to the container before it has concluded its build. Anyone with sufficient access to the platform that hosts the Envbuilder container will also be able to read these build secrets from where the platform stores them. This is true for other build systems, and containerised software in general.
109
151
152
+
The secure way to use build secrets with Envbuilder is to deny users access to the platform that hosts Envbuilder. Only grant access to the Envbuilder container once it has concluded its build, using a trusted non-platform channel like ssh or the coder agent running inside the container. Once control has been handed to such a runtime container process, Envbuilder will have cleared all secrets that it set from the container.
153
+
110
154
If secrets should be accessible at runtime, do not use build secrets. Rather, mount the secret data using a volume or environment variable. Envbuilder will not include mounted volumes in the image that it pushes to any cache repositories, but they will still be available to users that connect to the container.
111
155
112
156
### Container Management beyond Envbuilder's control
0 commit comments