Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Using SSH keys to authenticate kustomize bases from git #827

Closed
arnarg opened this issue Nov 22, 2018 · 6 comments
Closed

Using SSH keys to authenticate kustomize bases from git #827

arnarg opened this issue Nov 22, 2018 · 6 comments
Assignees
Labels
enhancement New feature or request
Milestone

Comments

@arnarg
Copy link
Contributor

arnarg commented Nov 22, 2018

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
Copy link
Member

@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
Copy link
Contributor Author

arnarg commented Nov 24, 2018

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.

@jessesuen jessesuen added the enhancement New feature or request label Nov 27, 2018
@andreyvelich
Copy link

@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
Copy link

stale bot commented Jun 5, 2019

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.

@stale stale bot added the wontfix This will not be worked on label Jun 5, 2019
@alexmt alexmt removed the wontfix This will not be worked on label Jun 5, 2019
@alexec alexec added this to the v1.1 milestone Jun 6, 2019
@alexec alexec assigned alexec and unassigned alexec Jun 7, 2019
@alexec alexec self-assigned this Jun 11, 2019
@alexec
Copy link
Contributor

alexec commented Jun 14, 2019

Fixed. In v1.1

@alexec alexec closed this as completed Jun 14, 2019
@karlschriek
Copy link

karlschriek commented Feb 4, 2022

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

6 participants