Persistent GPG Server Key

[kvaps]

Summary

Currently Argo CD generating new gpg key pair each start:

https://github.com/argoproj/argo-cd/blob/ea9b0b35d0a2f996066b2d41315ff575d38eadc9/util/gpg/gpg.go#L256-L267

Right now this key is not much useful because changing each restart. But if it would be persistent, it would allow to use it to simple decrypt the repository using git-crypt or sops.

Motivation

Simple and native Git-based encryption for the Argo CD.

Example use case:

• Initial ArgoCD installation generates gpg-server key.
• User is logging in to ArgoCD interface and able to download public key for this server
• User encrypting his Git repository using for this gpg-key.
• During the deployment ArgoCD able to decrypt the repository using it's gpg key.

eg. simple command git-crypt unlock is enough after fetching

Proposal

• Initial ArgoCD installation should generate persistent gpg-server key if another one is not existing yet and write it to argocd-gpg-keys-secret secret.

• This key should be stored in specific secret and mounted to argocd-repo-server container for automatic loading during the startup (this is already implemented):

    volumes:
    - name: gpg-keys
      projected:
        sources:
        - secret:
          name: argocd-gpg-keys-secret
        - configMap:
          name: argocd-gpg-keys-cm

• Additionally an opportunity for adding additional persistent gpg keys in Argo CD interface might be implemented.

[kvaps]

Read my article about how I made this working already now: https://itnext.io/configure-custom-tooling-in-argo-cd-a4948d95626e#567a

Meanwhile it would be nice to have native support in ArgoCD.

[jessesuen]

I think @jannfis should chime in here

[jannfis]

Actually, I do like the idea of Argo CD maintaining a GPG keyring for Git decryption purposes. However, I'm not sure if I fully agree with the above proposal. The current design makes some assumptions about the purpose of the keyring which it manages, the most important one being that the keys are non-critical when being leaked - i.e. they are public keys, and the necessary private key is transient.

I'd propose a bring-your-own-key only approach and building a different keyring, containing only the private key(s), for the special purpose of decryption purposes. But I'm unsure whether it's a good idea to use a secret mount for private key(s), due to very lax file system permissions from these kind of mounts. The argocd-repo-server however doesn't talk to the K8s API, so we cannot access any Secret from it either.

I'm happy to discuss this further and come up with an implementation, but we should make sure it's securely implemented - after all, it will be a secret that unlocks other secrets, so probably a very valuable target for any kind of adversaries.

[kvaps]

@jannfis alternatively git-crypt allows to export symmetric key for the each repository.

Such keys might be stored separated per repository in ArgoCD, similarly Gitlab CI Sercret Variables, and will be used to decrypt only their specific repository.

to export key:

git-crypt export-key /some/secretfile

secretfile will contain binary data

to unlock the repository using symmetric key

git-crypt unlock /some/secretfile

not sure if SOPS supports the similar approach.

[btrepp]

Any ideas on what next steps would be @jannfis. I was chasing a similar thing for passwordstore referenced as a submodule. This is part of a project to help kustomize expand secrets from passwordstore

A key part of the security model would not be allowing anyone to use the key, otherwise a tenant could clone from a protected repo, and get argocd to spew out the secrets.

Perhaps there could be a private key per app project?. This would at least prevent it from being cluster wide.

It could also be tied to the application. So you could be targeted. Eg this application uses this key.

I'm not sure of the implementation. Eg is repo server even aware of appprojects or projects?. Or is it mainly responsible for expanding templates :).

[xbitres]

Are there any updates on this topic? Maybe it would make sense to assign to another maintainer?

[jannfis]

We currently think it's a bad idea to store secrets in the repository server, especially in multi-tenant scenarios.

This may change in the future however, but until then, this feature will not be implemented.