Authenticate from mounted secrets and stop passing the password to seaf-cli
The password could only be given through the PASSWORD variable, so Docker Compose and Swarm secrets were unusable and the password sat in the container environment. PASSWORD_FILE and TOKEN_FILE read a secret from a mounted file. Only trailing newlines are stripped, since secret files are usually written with one and a password that silently carries it just fails to authenticate; everything else, including surrounding spaces, belongs to the secret. Setting both a variable and a file for one secret is rejected rather than resolved by precedence, because the two are meant to be the same value and quietly picking one hides the mistake until authentication fails. The installed seaf-cli supports token authentication and ignores the password when a token is given, so sync now passes -T instead of -p. The account password no longer appears in any command line. The token does, because seaf-cli accepts credentials only as arguments, but a token can be revoked on the server. This is documented in the README. Both secrets are masked before a command is logged. Tests cover newline handling, empty and missing files, conflicting sources, and that neither secret reaches the logs. Requests are now blocked in tests: the client retries with backoff, so a test that reached the network appeared to hang instead of failing.
This commit is contained in:
1 parent
1e59da6193
commit
eef0e453bf
11 files changed
+288
-36
No files matched your search
@@ -36,6 +36,11 @@ volumes:
|
||||
If you're using non-standard port, you can specify it here,
|
||||
eg: _seafile.example.com:8080_.
|
||||
- `USERNAME` / `PASSWORD` - credentials to access Seafile server.
|
||||
- `PASSWORD_FILE` - path to a file holding the password, for Docker Compose
|
||||
and Swarm secrets. Use either `PASSWORD` or `PASSWORD_FILE`, never both.
|
||||
- `TOKEN` / `TOKEN_FILE` - an API token to authenticate with instead of a
|
||||
password. A token takes precedence over a password and can be revoked on the
|
||||
server. Use either `TOKEN` or `TOKEN_FILE`, never both.
|
||||
- `SEAFILE_UID` / `SEAFILE_GID` - UID/GID of user inside container. You can
|
||||
use it to set permissions on synced files. Default values are _1000_ / _1000_.
|
||||
- `DELETE_CONFIRM_THRESHOLD` - represents the number of files that require
|
||||
@@ -45,6 +50,32 @@ volumes:
|
||||
- `UPLOAD_LIMIT` / `DOWNLOAD_LIMIT` - upload/download speed limit in B/s
|
||||
(bytes per second). Default values are _0_ (unlimited).
|
||||
|
||||
### Using Docker secrets:
|
||||
Mount the secret and point `PASSWORD_FILE` at it, so the password never enters
|
||||
the environment:
|
||||
|
||||
```yaml
|
||||
services:
|
||||
seafile-client:
|
||||
environment:
|
||||
PASSWORD_FILE: /run/secrets/seafile_password
|
||||
secrets:
|
||||
- seafile_password
|
||||
|
||||
secrets:
|
||||
seafile_password:
|
||||
file: ./seafile_password.txt
|
||||
```
|
||||
|
||||
A trailing newline in the file is ignored; everything else, including
|
||||
surrounding spaces, is part of the secret.
|
||||
|
||||
The client authenticates `seaf-cli` with an API token rather than the account
|
||||
password, so the password never appears in a command line. The token does
|
||||
appear there, and command lines are visible to any process in the container.
|
||||
This is a limitation of `seaf-cli`, which accepts credentials only as
|
||||
arguments. A token can at least be revoked on the server.
|
||||
|
||||
### Volumes:
|
||||
- `/dsc/seafile-data` Seafile client data directory (sync status, etc).
|
||||
- `/dsc/seafile` Seafile libraries content.
|
||||
|
||||
Reference in new issue
Block a user