terraform-provider-argocd
terraform-provider-argocd copied to clipboard
Can this provider use an ED25519 key as a deploy key to talk to a repo?
Terraform Version, ArgoCD Provider Version and ArgoCD Version
Terraform version: 1.7.5
ArgoCD provider version: 6.1.1
ArgoCD version: v2.10.2+fcf5d8c.dirty
Terraform configuration
terraform {
required_providers {
azurerm = {
source = "hashicorp/azurerm"
version = "~>3.0"
}
argocd = {
source = "oboukili/argocd"
version = "~>6.1.1"
}
}
}
provider "argocd" {
port_forward = true
kubernetes {
host = azurerm_kubernetes_cluster.aks-argocd.kube_config.0.host
client_certificate = base64decode(azurerm_kubernetes_cluster.aks-argocd.kube_config.0.client_certificate)
client_key = base64decode(azurerm_kubernetes_cluster.aks-argocd.kube_config.0.client_key)
cluster_ca_certificate = base64decode(azurerm_kubernetes_cluster.aks-argocd.kube_config.0.cluster_ca_certificate)
}
}
resource "argocd_repository" "helm_charts" {
repo = "[email protected]:omitted/omitted.git"
username = "git"
ssh_private_key = var.helm_charts_private_key
insecure = true
}
var.helm_charts_private_key does not have a default value. It is supplied during GitHub Actions from a GitHub Secret.
Question
I'm trying to use an ed25519 deploy key for ssh access to the repository. The key exists in the "deploy keys" portion of the repository already. I'm trying to configure our ArgoCD cluster via the provider to talk to the repo. I've supplied the ed25519 private key into GitHub Secrets and verified that the value is being passed into the var.helm_charts_private_key variable.
Does the provider accept deploy keys as ed25519?
It seems when hitting the ParseSshKey method, openssh doesn't like it:
Error: ssh_private_key: invalid ssh private key: ssh: no key found
...during terraform plan step.
Any updates on this? We are able to deploy argocd with a key which fails to parse in the argocd terraform setup. This is blocking our effort to move our argocd bootstrap to terraform
Let me take a look at it...
I can reproduce the issue with the following procedure:
kind create cluster --name argocd
kubectl create namespace argocd
kubectl apply -f https://github.com/argoproj/argo-cd/raw/refs/tags/v2.12.4/manifests/install.yaml -n argocd
ssh-keygen -t ed25519 -C "Argo CD Testing"
Using this terraform snippet:
terraform {
required_providers {
argocd = {
source = "oboukili/argocd"
version = "6.1.1"
}
}
}
variable "ssh_key" {
type = string
description = "PEM encoded ssh key to use"
}
variable "argocd_password" {
type = string
description = "Argo CD Admin password"
}
provider "argocd" {
port_forward_with_namespace = "argocd"
username = "admin"
password = var.argocd_password
kubernetes {
config_context = "kind-argocd"
}
}
resource "argocd_repository" "test_repo" {
repo = "[email protected]:the-technat/the-technat.git"
username = "git"
ssh_private_key = var.ssh_key
insecure = true
}
And then running:
export TF_VAR_argocd_password="$(kubectl -n argocd get secrets argocd-initial-admin-secret -o jsonpath='{.data.password}' | base64 -d)"
export TF_VAR_ssh_key="<ed25519 private key>"
terraform init
terraform apply -auto-approve
The following points have been observed:
- With an RSA key, the provider throws an error when trying to verify if the ssh key is valid (which he's not)
- With an ED25519 key, the provider immediately throws the error
ssh_private_key: invalid ssh private key: ssh: no key found, without even trying to connect to the argocd api (e.g an invalid provider config could be specified) nor github to validate the key.
=> This must be an issue in the validate function of the ssh_key param. I can see that the used ParsePrivateKey function calls some other functions that might not support ED25519. But I'll have to investigate that further.
Really strange, when I set the private key without "", it seems to work.
@Vermyndax can you validate in which format you set the variable for the private key and try to change something on the format? Maybe try setting the variable for your private key without quotation marks like so: export TF_VAR_ssh_key="$(cat ~/.ssh/id_ed25519)"?
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.
Whoops, sorry about the lack of response here. I will check on this when I return from holiday break.
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.
@Vermyndax were you able to check/verify?
Hi, yes I was able to check this and it worked. Sorry I didn't respond.
No worries, glad it worked. I'm going to close the issue now?