Skip to content

Commit

Permalink
Merge pull request containers#430 from cgwalters/more-customization
Browse files Browse the repository at this point in the history
docs: Extend build guidance with secrets
  • Loading branch information
jeckersb authored Mar 26, 2024
2 parents 0c250ea + 4890cc9 commit 11093ee
Show file tree
Hide file tree
Showing 3 changed files with 58 additions and 2 deletions.
1 change: 1 addition & 0 deletions docs/src/SUMMARY.md
Original file line number Diff line number Diff line change
Expand Up @@ -10,6 +10,7 @@

- [Building images](building/guidance.md)
- [Users, groups, SSH keys](building/users-and-groups.md)
- [Secrets](building/secrets.md)

# Using bootc

Expand Down
8 changes: 6 additions & 2 deletions docs/src/building/guidance.md
Original file line number Diff line number Diff line change
Expand Up @@ -50,8 +50,8 @@ and if you embed software in your derived image, the
default would then be that that software is initially
launched via a systemd unit.

```
RUN dnf -y install postgresql
```dockerfile
RUN dnf -y install postgresql && dnf clean all
```

Would typically also carry a systemd unit, and that
Expand Down Expand Up @@ -88,3 +88,7 @@ make in the container image to e.g. `/etc/postgresql.conf`
will be applied on update, assuming it is not modified
locally.

### Secrets

There is a dedicated document for [secrets](secrets.md),
which is a special case of configuration.
51 changes: 51 additions & 0 deletions docs/src/building/secrets.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,51 @@

# Secrets (e.g. container pull secrets)

To have `bootc` fetch updates from registry which requires authentication,
you must include a pull secret in `/etc/ostree/auth.json`.

Another common case is to also fetch container images via
`podman` or equivalent. There is a [pull request to add `/etc/containers/auth.json`](https://github.com/containers/image/pull/1746)
which would be shared by the two stacks by default.

Regardless, injecting this data is a good example of a generic
"secret". The bootc project does not currently include one
single opinionated mechanism for secrets.

## Embedding in container build

This was mentioned above; you can include secrets in
the container image if the registry server is suitably protected.

In some cases, embedding only "bootstrap" secrets into the container
image is a viable pattern, especially alongside a mechanism for
having a machine authenticate to a cluster. In this pattern,
a provisioning tool (whether run as part of the host system
or a container image) uses the bootstrap secret to lay down
and keep updated other secrets (for example, SSH keys,
certificates).

## Via cloud metadata

Most production IaaS systems support a "metadata server" or equivalent
which can securely host secrets - particularly "bootstrap secrets".
Your container image can include tooling such as `cloud-init`
or `ignition` which fetches these secrets.

## Embedded in disk images

Another pattern is to embed bootstrap secrets only in disk images.
For example, when generating a cloud disk image (AMI, OpenStack glance image, etc.)
from an input container image, the disk image can contain secrets that
are effectively machine-local state. Rotating them would
require an additional management tool, or refreshing disk images.

## Injected via baremetal installers

It is common for installer tools to support injecting configuration
which can commonly cover secrets like this.

## Injecting secrets via systemd credentials

The systemd project has documentation for [credentials](https://systemd.io/CREDENTIALS/)
which applies in some deployment methodologies.

0 comments on commit 11093ee

Please sign in to comment.