containers / fetchit

FetchIt is used to manage the life cycle and configuration of Podman containers
https://fetchit.readthedocs.io/
GNU Affero General Public License v3.0
124 stars 23 forks source link

RFE: Support podman secrets for private repos #272

Closed cevich closed 1 year ago

cevich commented 1 year ago

It's considered a fairly universally bad thing to commit credentials into git. Since the preferred method of using Fetchit is with a podman container, reading a PAT (or username/password) from a secret should be pretty easy. Perhaps a simple config. attribute and env. var. could be used to name the secret. For example:

configReload:
  schedule: "*/5 * * * *"
   secret_pat: PINKPANTHER
  configUrl: https://raw.githubusercontent.com/containers/fetchit/main/examples/config-reload.yaml

and

$ echo "SuperDuperSecretPATNobodyKnows" | \
    podman secret create PINKPANTHER -
$ podman run -d --rm --name fetchit --secret PINKPANTHER,type=env ...mount options... quay.io/fetchit/fetchit:latest

Fetchit would then know to lookup the PAT value by examining $PINKPANTHER. Since it's a secret, podman would guarantee it never shows up in container storage or a committed image.

Something similar could be done purely using env. vars to point at the secret:

$ export FETCHIT_CONFIG_URL=https://raw.githubusercontent.com/containers/fetchit/main/examples/config-reload.yaml
$ export FETCHIT_SECRET_PAT=PINKPANTHER
$ podman run -d --rm --name fetchit --secret PINKPANTHER,type=env -e FETCHIT_CONFIG_URL -e FETCHIT_SECRET_PAT ...other options... quay.io/fetchit/fetchit:latest
cooktheryan commented 1 year ago

@cevich completely agree. We have a start for using ssh private keys for the credentials but there is currently a bug in the git pull portion of the code

cevich commented 1 year ago

I'm not a go expert, but I can be dangerous. Have I read the code correctly in that most of this feature only needs updates to pkg/engine/config.go?

It seems the hard-part is getting the shadowing logic correct for env. vars. vs config files. It seems in some cases env. vars overwrite, but not in others.

sallyom commented 1 year ago

@cevich sorry for the delay in response - the Auth types are defined here: https://github.com/containers/fetchit/blob/main/pkg/engine/gitauth.go so you'd introduce a Secret there, then, in config.go, similar to how the PAT is unpacked from GitAuth here: https://github.com/containers/fetchit/blob/f5ffd62ecd0c7dd705ca90d3b8afcf6dd1be1e45/pkg/engine/config.go#L27-#L59 we'd add a bit to first unpack PAT from Secret. I haven't used podman secrets much, if you don't have the cycles to do this let me know I'll give it a go this week. Thanks for the issue, totally should be using secrets here.

cevich commented 1 year ago

if you don't have the cycles to do this let me know I'll give it a go this week.

I'd like to make time for it, but certainly not this week. My rust is a bit gooey...err...my go is a bit rusty...err...wait, is this go or rust :rofl: Honestly, if you think it can wait for my slowness, I'd like to do it. But I totally understand wanting a feature like this quickly, so no biggie.

I haven't used podman secrets much

They're isn't much to learn. You add one into podman (setting it's value). Then at podman run time either present it as an env. var. or as a file inside the container. The files show up with the secret's name, under /run/secrets/, the env. vars. simply show up. In either case, podman guarantees neither will ever get committed into a image or an export. I can't remember if they're supported with podman play kube YAML or not, in any case that was/is certainly something hotly discussed.

Also in case it matters: The secret values are "sticky". So if you change one after starting a container, the container will continue to use the previous value. Obviously any new container would get the new value.

HTH