17. 07. 2024 Lorenzo Candeago DevOps

How to Add SSH Keys to ArgoCD and Tekton on OpenShift to Access Gitea: Part1 – Set up the Test Environment and Add SSH Key to Gitea

In this series of blog posts I’ll show you how to set up ArgoCD and Tekton to clone git repositories via ssh from a Gitea instance hosted on an OpenShift cluster. Please note that for the sake of this blog post, the configurations are not suited for use in production, but just to give you a general idea of how it can be done. For our testing environment, we’ll set up a local instance of Red Hat CodeReady Containers on our local machine.

First we need to set up Redhat Codeready Containers (crc). After downloading the crc installer, we can run the setup. For using ArgoCD we will need some extra resources: for our test, a disk of 120GB and 6 CPUs is enough.

Let’s set up crc adding that extra CPU/disk:

crc setup
crc start  -c 6 -d 120
eval $(crc oc-env)
oc login -u kubeadmin https://api.crc.testing:6443

Now we can install Gitea using the official helm chart

First of all let’s create a custom values.yaml that will be used for the helm chart. (Remember, this is not a production setup!) We need to grant extra capabilities to be able to use ssh with Gitea due to to this bug. Let’s create gitea_custom_values.yaml now:

service:
  http:
    port: 3000
  ssh:
    port: 2222

# https://gitea.com/gitea/helm-chart/issues/161
securityContext:
  capabilities:
    add: ["SYS_CHROOT"]
# non HA testing setup, not suitable for production
redis-cluster:
  enabled: false
redis:
  enabled: false
postgresql:
  enabled: false
postgresql-ha:
  enabled: false

persistence:
  enabled: false

gitea:
  config:
    database:
      DB_TYPE: sqlite3
    session:
      PROVIDER: memory
    cache:
      ADAPTER: memory
    queue:
      TYPE: level

Let’s deploy our helm chart. To be sure we’re deploying the helm chart to the correct cluster (in the case where you’re managing multiple OpenShift clusters) we can use the option –kube-context with helm:

helm  repo add gitea-charts https://dl.gitea.com/charts/ --kube-context=crc-admin
helm install gitea gitea-charts/gitea --values gitea_custom_values.yaml --kube-context=crc-admin

Since this is a test environment, we can just forward our Gitea’s HTTPS and SSH ports to our localhost:

oc --namespace default port-forward svc/gitea-http 3000
oc --namespace default port-forward svc/gitea-http 2222

Now we can access our Gitea instance, so let’s find the admin password:

oc get deployment gitea -n default -o yaml | grep 'GITEA_ADMIN_PASSWORD$' -A 1
        - name: GITEA_ADMIN_PASSWORD
          value: r8sA8CPHD9!bt6d

And next, let’s generate an ssh key pair that will be used to access the repo:

 ssh-keygen -t ed25519 
Generating public/private ed25519 key pair.
Enter file in which to save the key (/home/lo/.ssh/id_ed25519): ./id_ed25519
Enter passphrase (empty for no passphrase): 
Enter same passphrase again: 
Your identification has been saved in ./id_ed25519
Your public key has been saved in ./id_ed25519.pub
The key fingerprint is:
SHA256:MmkCWYLv1hNfrnxxLz3neW07kIftSijyYtYrv5w2kkU lo@localhost.localdomain
+----[SHA256]-----+

And add the public key to Gitea:

And then we can verify the key and paste the generated signature:

echo -n '8d1090c9c5561836dff5d8c6c8f69fcfd5463726f2bce695437cce0ddb360185' | ssh-keygen -Y sign -n gitea -f ./id_ed25519         
Signing data on standard input
-----BEGIN SSH SIGNATURE-----
U1NIU0lHAAAAAQAAADMAAAALc3NoLWVkMjU1MTkAAAAgqOaxaNpUF3qZByNvKZB2ZUWXcS
Ar8QfmLv+FfzzX4xsAAAAFZ2l0ZWEAAAAAAAAABnNoYTUxMgAAAFMAAAALc3NoLWVkMjU1
MTkAAABALU0jOKyxpPSr6cLLrdLaUumRwwi9ps1wvpNmPlxhkeeyl3q357Z+VtGMYCIJp0
KDLXZvsPCRZFSuPYeK9gt5CA==
-----END SSH SIGNATURE-----

Finally let’s create a test repo and check that we can actually clone it via ssh:

GIT_SSH_COMMAND='ssh -i ./id_ed25519 -o IdentitiesOnly=yes -p 2222' git clone git@127.0.0.1:gitea_admin/test-repo.git

In my next blog post, we’ll set up OpenShift GitOps operator (that is, ArgoCD + Tekton) and look at how to add the ssh key as a secret in ArgoCD and run a simple test deployment.

Lorenzo Candeago

Lorenzo Candeago

DevOps Engineer at Würth Phoenix

Author

Lorenzo Candeago

DevOps Engineer at Würth Phoenix

Leave a Reply

Your email address will not be published. Required fields are marked *

Archive