ArgoCD UI exposed publicly

GitOps Argo CD
#1

Hi guys,
I have a bad feeling knowing that ArgoCD UI is publicly accessible with just a username and password authentication enabled, it doesn’t look like a safe option to me.
Is there any way to restrict this access and what’s the best practice in that case?
I’m deploying ArgoCD with Helm Terraform provider currently and using this annotation to create a LB that will point to ArgoCD service:

resource "helm_release" "argocd" {
  name       = "argocd"
  repository = "https://argoproj.github.io/argo-helm"
  chart      = "argo-cd"
  version    = "${var.argocd_version}"

  namespace = "argocd"

  create_namespace = true

set {
    name  = "server.service.type"
    value = "LoadBalancer" ## To change the argocd-server svc default ClusterIp type
  }

  set {
    name  = "server.service.annotations.service\\.beta\\.kubernetes\\.io/aws-load-balancer-type"
    value = "alb"
  }

Thanks!

#2

This is a very legitimate concern. It tends to be less stressed in introductory courses because a lot of what you need to do to secure a system like argocd also makes the installs more brittle, and harder to get started with. Since you want people to be able to concentrate on learning the basics, this can be problematic.

But once you’ve learned the basics, very true, you need to be concerned about this. Here’s some of the best practices that people think about for ArgoCD.

#3

Thanks for the response Rob! So nothing like IP filtering or deploying a private load balancer in front of the service is considered as a common practice?

#4

Haven’t done it myself, TBH. But the project docs on security should give you an idea what they tell people to do.

#5

Key thing here is Ingress.

On a cluster that has world-facing applications, you would deploy two ingress controllers. One for the public apps, and one for the tooling like Argo. That ingress would only be accessible to internal networks. Loadbalancer services should only be used for the ingress controllers. Everything else, including Argo should deploy an ingress resource with ingressClassName set to the class of the internally facing ingress. And yes, it would be an internally facing LB for the tools ingress, which would also serve Prometheus and things like that.
The argo chart will have values settings for configuring it as ClusterIP with Ingress.

Personally I am not a fan of using terraform to deploy helm charts, although if ingress controllers and Argo are the only things you’re deploying that way as part of a new cluster build, then it’s probably OK.

#6

Thanks @Alistair_KodeKloud , that’s very helpful!