Secrets concept

fnetX commented

2022-11-05 21:28:05 +01:00

Owner

We decided to store and source secrets from the server (if someone has read access to the config files anyway, why not also allow them to read the password directly :D).

Currently, the approach by @Gusted just sources one file, that's it.

I propose to expand this to the following:

there lives a secrets folder in /root/
subfolders for each container
every file inside is sourced, strings are prefixed by the container, e.g. MARIADB_GITEA_PRODUCTION, MARIADB_GITEA_STAGING etc
they are collected in a secrets folder on the root machine per container
a host can share secrets with another host by naming the file like the target host (or symlinking)
- e.g. inside mariadb container: gitea-staging.sh -> ./staging-passwords.sh
- e.g. inside redis container: gitea-production.sh -> ./production-secrets.sh
these secrets are then synched across machines where the sharing machine is the "primary" / source of truth

Examples:

mariadb:

./mariadb/gitea-staging.sh
./mariadb/gitea-produciton.sh
./mariadb/mariadb.sh (only internal use, e.g. root)

redis:

./redis/redis.sh
./redis/gitea-staging.sh -> redis.sh
./redis/gitea-production.sh -> redis.sh (same file shared to two machines)

gitea-staging.sh

./gitea-staging/gitea-staging.sh (nearly everything)
./redis/gitea-staging.sh
./mariadb/gitea-staging.sh (both shared from other machines)

Does this make sense? Too complicated? (Symlinking is not necessary, but could be easier if some secret should be shared to multiple machines)

We decided to store and source secrets from the server (if someone has read access to the config files anyway, why not also allow them to read the password directly :D). Currently, the approach by @Gusted just sources one file, that's it. I propose to expand this to the following: - there lives a `secrets` folder in /root/ - subfolders for each container - every file inside is sourced, strings are prefixed by the container, e.g. MARIADB_GITEA_PRODUCTION, MARIADB_GITEA_STAGING etc - they are collected in a secrets folder on the root machine per container - a host can share secrets with another host by naming the file like the target host (or symlinking) - e.g. inside mariadb container: gitea-staging.sh -> ./staging-passwords.sh - e.g. inside redis container: gitea-production.sh -> ./production-secrets.sh - these secrets are then synched across machines where the sharing machine is the "primary" / source of truth Examples: mariadb: ~~~ ./mariadb/gitea-staging.sh ./mariadb/gitea-produciton.sh ./mariadb/mariadb.sh (only internal use, e.g. root) ~~~ redis: ~~~ ./redis/redis.sh ./redis/gitea-staging.sh -> redis.sh ./redis/gitea-production.sh -> redis.sh (same file shared to two machines) ~~~ gitea-staging.sh ~~~ ./gitea-staging/gitea-staging.sh (nearly everything) ./redis/gitea-staging.sh ./mariadb/gitea-staging.sh (both shared from other machines) ~~~ Does this make sense? Too complicated? (Symlinking is not necessary, but could be easier if some secret should be shared to multiple machines)

fnetX commented

2022-11-05 21:28:38 +01:00

Author

Owner

Oh and BTW, I think the function should be called secret_get () so theat we use the first part as prefix for the base filename to avoid conflicts.

Bubu commented

2022-11-05 22:30:09 +01:00

Member

I'm quite confused by this actually. :-D

How would the weblate setup need to be changed to conform to this scheme?

I'm quite confused by this actually. :-D How would the weblate setup need to be changed to conform to this scheme?

fnetX commented

2022-11-05 23:37:47 +01:00

Author

Owner

Do you already use the secrets function?

If you don't rely on other services, you just place a /root/secrets/weblate/weblate.sh (or name the file whatever you want inside the weblate folder), and put your strings there as shell variables, e.g.

WEBLATE_ADMIN_PASSWORD="abc"
WEBLATE_API_KEY="def"
WEBLATE_LOCAL_DATABASE="xyz"

You can then get these secrets on the host using secret_get VARNAME inside the scripts.

Do you already use the secrets function? If you don't rely on other services, you just place a /root/secrets/weblate/weblate.sh (or name the file whatever you want inside the weblate folder), and put your strings there as shell variables, e.g. ~~~ WEBLATE_ADMIN_PASSWORD="abc" WEBLATE_API_KEY="def" WEBLATE_LOCAL_DATABASE="xyz" ~~~ You can then get these secrets on the host using `secret_get VARNAME` inside the scripts.

fnetX commented

2022-11-05 23:38:58 +01:00

Author

Owner

The confusing stuff is only for sharing secrets between hosts. E.g. when weblate is using the database which is configured inside the mariadb container, the mariadb container would expose a "mariadb/weblate.sh" file, which will then be available in your container. You could then use secret_get MARIADB_WEBLATE_PASSWORD or something like this in your script.

The confusing stuff is only for sharing secrets between hosts. E.g. when weblate is using the database which is configured inside the mariadb container, the mariadb container would expose a "mariadb/weblate.sh" file, which will then be available in your container. You could then use `secret_get MARIADB_WEBLATE_PASSWORD` or something like this in your script.

Gusted commented

2022-11-07 15:11:07 +01:00

Owner

a host can share secrets with another host by naming the file like the target host (or symlinking)

Is this a hard can? As lets say a container is compromised, it shouldn't automatically have access to all other secrets. So ideally it's always an option to share the secret.

For the other parts of the proposal, LGTM. My script is quick and hacky but works how it should work.

> a host can share secrets with another host by naming the file like the target host (or symlinking) Is this a **hard** can? As lets say a container is compromised, it shouldn't automatically have access to all other secrets. So ideally it's always an option to share the secret. ---- For the other parts of the proposal, LGTM. My script is quick and hacky but works how it should work.

fnetX commented

2022-11-07 16:17:22 +01:00

Author

Owner

My approach is push, not pull. A compromised container could push secrets to other containers (which are only taken after someone triggers a deployment there). But it cannot pull secrets which weren't shared with it.

If you name a file like the target container, it will just show up there, but won't grant you access to secrets on that host which weren't explicitly shared to outside that container.

My approach is push, not pull. A compromised container could push secrets to other containers (which are only taken *after* someone triggers a deployment there). But it cannot pull secrets which weren't shared with it. If you name a file like the target container, it will just show up there, but won't grant you access to secrets on that host which weren't explicitly shared to outside that container.

Gusted commented

2022-11-07 16:53:55 +01:00

Owner

My approach is push, not pull. A compromised container could push secrets to other containers (which are only taken after someone triggers a deployment there). But it cannot pull secrets which weren't shared with it.

Alright, that's good to know.

> My approach is push, not pull. A compromised container could push secrets to other containers (which are only taken after someone triggers a deployment there). But it cannot pull secrets which weren't shared with it. Alright, that's good to know.

Rows
Columns

Secrets concept #5