1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
|
---
title: Handling secrets in your build manifests
---
# Handling secrets in your build manifests
builds.sr.ht can be used to automate the deployment of websites, signing of
packages, and more, through the use of **build secrets**. You can upload the
secret keys necessary to run your automation on the web, then make these secrets
available to CI jobs.
## Our example build manifest
Let's say we have a git repo with static HTML files that we'd like to deploy by
sending them to our webserver. A simple build manifest might look like this:
```yml
image: alpine/edge
packages:
- rsync
sources:
- https://git.sr.ht/~you/example.org
tasks:
- upload: |
rsync -r example.org/* example.org:/var/www/
```
This is straightforward enough - but it won't work because the build won't have
authorization to log into example.org.
## Generating the secrets & preparing our server
This step will naturally be somewhat different depending on your particular
server configuration. You should start by creating a deploy user:
useradd -m deploy
Let's also give this user permission to update `/var/www`:
usermod -aG www-data deploy
chgrp www-data /var/www
chmod g+rwx /var/www
And finally, let's log in as "deploy" and generate an SSH key:
sudo su deploy
ssh-keygen
# accept the defaults
cat .ssh/id_rsa.pub >> .ssh/authorized_keys
cat .ssh/id_rsa
This will print out the new SSH private key. Copy this to your clipboard for the
next step.
## Adding your secret to builds.sr.ht
Go to the [builds.sr.ht secret management
dashboard](https://builds.sr.ht/secrets) and select "SSH key" for secret type,
then paste your key into the textbox. Click "submit" - and your new secret
should show up on the right, along with its UUID.
This UUID is used to uniquely identify this secret in build manifets. Copy this
UUID for the next step.
## Adding secrets to your build manifest
This part is easy. We can simply add a list of secret UUIDs we want to be
available in this build.
```yml
image: alpine/edge
secrets:
- c262b238-41de-4b43-a2f9-460424dd7896
packages:
- rsync
sources:
- https://git.sr.ht/~you/example.org
tasks:
- upload: |
rsync -r example.org/* example.org:/var/www/
```
It's as easy as that! builds.sr.ht will install this SSH key into your build
environment when you submit this build manifest. However, it will only work for
builds submitted with your user - if someone else copies and pastes this build
manifest, the SSH key will not be added to their build VM.
## Controlling the use of secrets
The easiest way to control whether or not secrets work in your build is by
turning them off via the API: if you set secrets=false in [POST
/api/jobs](/builds.sr.ht/api.md#post-apijobs), the secrets will not be resolved.
This is automatically done in many places where the build manifest could be
modified by an untrusted party - for example, dispatch.sr.ht disables secrets
when submitting build manifests from GitHub pull requests.
However, some degree of responsibility lies with you for keeping your secrets
secure. Avoid writing build manifests that would print your secrets to the logs,
particularly if using file secrets. If a secret is every leaked in this manner,
you should consider that secret compromised - revoke it and generate a new one.
---
<div class="alert alert-info">
<strong>Want to learn more about builds.sr.ht?</strong>
Check out all of our <a href="builds.sr.ht">builds.sr.ht tutorials</a>.
</div>
Other resources:
- [builds.sr.ht secrets manual](/builds.sr.ht/#secrets)
|
