Skip to content

Commit f287c49

Browse files
authored
docs: Add documentation for using secrets (#112)
1 parent 635b3b8 commit f287c49

1 file changed

Lines changed: 124 additions & 0 deletions

File tree

src/content/docs/reference/module.mdx

Lines changed: 124 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -41,6 +41,130 @@ snippets:
4141

4242
A list of secrets to mount when running the module. These secrets are available to the module's script and can be used only by it.
4343

44+
Creating a secret takes 2 parts:
45+
46+
1. Specifying an environment variable, command, or file on the host containing the secret
47+
2. Defining the environment variable or file in the build to contain the secret
48+
49+
#### Host Side
50+
51+
In order to use a secret in the build, you will have to have it accessible on the host machine. This can come in the form of an environment variable, a file, the ssh socket, or a command that's ran to retrieve the secret. The type of the secret can be specified with the `type:` property.
52+
53+
##### Environment Variable
54+
55+
You can use `type: env` to pull the value of an environment variable as a secret.
56+
57+
```yaml
58+
modules:
59+
- type: script
60+
secrets:
61+
- type: env
62+
name: SECRET_ENV
63+
mount:
64+
type: env
65+
name: SECRET_ENV
66+
snippets:
67+
- echo $SECRET_ENV | login-script.sh
68+
```
69+
70+
##### File
71+
72+
You can use `type: file` to read the contents of a file as a secret. Relative paths are relative to the root of the `bluebuild` project.
73+
74+
```yaml
75+
modules:
76+
- type: script
77+
secrets:
78+
- type: file
79+
source: ./secret.txt
80+
mount:
81+
type: env
82+
name: SECRET_ENV
83+
snippets:
84+
- echo $SECRET_ENV | login-script.sh
85+
```
86+
87+
##### Command
88+
89+
You can use `type: exec` to execute a program/script that will retrieve the secret for you. The command must output the secret to `stdout`.
90+
91+
```yaml
92+
modules:
93+
- type: script
94+
secrets:
95+
- type: exec
96+
command: secret-manager-command
97+
args:
98+
- '-q'
99+
- some/arg/for/secret-command
100+
mount:
101+
type: env
102+
name: SECRET_ENV
103+
snippets:
104+
- echo $SECRET_ENV | login-script.sh
105+
```
106+
107+
##### SSH
108+
109+
You can use `type: ssh` to mount the SSH socket into the build. This is useful for pulling from private git repos, or SSHing into a private server to retrieve files. You will need to make sure you have an SSH session loaded before running the build. You can do this by running:
110+
111+
```bash
112+
# Start the ssh-agent and load env variables
113+
eval "$(ssh-agent)"
114+
115+
# Add your ssh key to the current agent
116+
ssh-add
117+
```
118+
119+
Example:
120+
121+
```yaml
122+
modules:
123+
- type: script
124+
secrets:
125+
- type: ssh
126+
snippets:
127+
- git clone git@github.com:some/repo.git
128+
```
129+
130+
#### Build side
131+
132+
When a secret is loaded from the host side, you will need to specify where to store the secret for that module run. Above we were using the `type: env` mount for demonstration purposes. You can combine most of the host side secrets (`env`, `file`, `exec`) to either build side mount (`env`, `file`). The `type: ssh` secret is mounted into the build for you, so a mount cannot be specified.
133+
134+
##### Environment variable
135+
136+
With `type: env`, a secret can be mounted into the build as an environment variable.
137+
138+
```yaml
139+
modules:
140+
- type: script
141+
secrets:
142+
- type: env
143+
name: SECRET_ENV
144+
mount:
145+
type: env
146+
name: SECRET_ENV
147+
snippets:
148+
- echo $SECRET_ENV | login-script.sh
149+
```
150+
151+
##### File
152+
153+
With `type: file`, a secret can be mounted into the build as a file.
154+
155+
```yaml
156+
modules:
157+
- type: script
158+
secrets:
159+
- type: env
160+
name: SECRET_ENV
161+
mount:
162+
type: file
163+
destination: /tmp/secret_file
164+
snippets:
165+
- cat /tmp/secret_file | login-script.sh
166+
```
167+
44168
## How modules are launched
45169

46170
A module added into an image's configuration is turned into a `RUN`-statement that launches the module with a JSON version of its configuration in the generated Containerfile (or an equivalent dynamic bash command if using the legacy template).

0 commit comments

Comments
 (0)