Using SSH keys to authenticate kustomize bases from git

[arnarg]

Kustomize bases can point to other git repositories like is shown here. The problem is that we have our base in a private bitbucket repository.
You can set the base to git::https://<user>:<app_pass>@bitbucket.org/org/repo.git and that works fine but storing that app_pass in a repository isn't optimal.
I managed to get SSH working using the base git::bitbucket.org:/org/repo.git and change the deployment of argo-repo-server to the following:

apiVersion: v1
kind: Secret
metadata:
  name: argocd-ssh-credential
type: Opaque
data:
  id_rsa: <ssh_private_key_in_base64>
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: argocd-repo-server
spec:
  template:
    spec:
      containers:
      - ...
        volumeMounts:
          - mountPath: /data
            name: id-rsa
        lifecycle:
          postStart:
            exec:
              command:
                - sh
                - "-c"
                - mkdir ~/.ssh && cat /data/id_rsa > ~/.ssh/id_rsa && chmod 400 ~/.ssh/id_rsa && ssh-keyscan bitbucket.org > ~/.ssh/known_hosts
      volumes:
        - name: id-rsa
          secret:
            secretName: argocd-ssh-credential
            defaultMode: 0444

Is there any way this could be supported more natively?
Either by using the same key as the repository used for the application or setting another one somehow.

[jessesuen]

@arnarg Your current workaround is the the recommended approach at the moment. Alternatively, you could have used an init container to copy the file to a shared emptyDir. See: https://github.com/argoproj/argo-cd/blob/master/docs/custom_tools.md

We will look into how we could formalize repo-server customizations through settings. Another example of where this is needed is with helm charts that need to use another remote helm repo as a dependency: #747

[arnarg]

I first tried it with emptyDir volume or mounting the secret directly under /home/argocd/.ssh but the user needs to own the private key and volumes are always owned by root.
I'm sure it can be done cleaner though.

[andreyvelich]

@jessesuen Hi! Any updates on this issue in the current ArgoCD version or we still need to manually add known host in ArgoCD server container?

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[alexec]

Fixed. In v1.1

[karlschriek]

This workaround no longer appears to be working (on v 2.2.3) with:

cannot create directory '/home/argocd/.ssh': Read-only file system

Still works if you additionally set readOnlyRootFilesystem: false though.

Mounting to an empytDir would be better though if the "owned by root" problem highlighted by @arnarg can be overcome.