ArgoCD: Use of Risky or Missing Cryptographic Algorithms in Redis Cache | Hacker News Reader

ArgoCD: Use of Risky or Missing Cryptographic Algorithms in Redis Cache

github.com

33 pointslis6 comments

FWIW: The Helm chart has network policy in place:

https://github.com/argoproj/argo-helm/blob/main/charts/argo-...

If you're using a CNI that supports network policy (e.g. AWS VPC CNI on EKS, Calico, etc.), I think this should more or less cover you, but I haven't personally tested it.

I think it's also probably a better practice to install "control plane" type software like Argo on a different, dedicated cluster. Argo supports this concept (and can in fact manage deployments in multiple clusters remotely). This way your main mission workloads are completely segmented from your privileged control plane software. Just as another defense-in-depth measure

ArgoCD not password protecting the Redis they deploy is amateur hour... Surely a Kubernetes-related (as in, it only exists as a wrapper around Kubernetes to make some of it less painful to use) should be aware that not only are all pods by default accessible by all other pods, but there's even an easy to use discovery for them? Not to mention that Kubernetes provides easy facilities to use to share secrets (Secrets objects, which aren't really secret because there's no encryption, but that's another topic).

> ArgoCD not password protecting the Redis they deploy is amateur hour...

An attacker would need to be inside your cluster/virtual/private network, no? You have bigger problems after that, right? This is an internally facing, not-externally-exposed Redis instance?

Yes, it's not an exploit that can be exploited unless you're already in the Kubernetes cluster; but it's an amazing privilege escalation, from being in the cluster to being full admin of it...

> ArgoCD not password protecting the Redis they deploy is amateur hour..

You can meme it with SPIFFE/SPIRE.

> Secrets objects, which aren't really secret because there's no encryption, but that's another topic

This isn't universally true anymore, at least with AWS EKS.

> This isn't universally true anymore, at least with AWS EKS.

The underlying etcd being encrypted at rest doesn't really change the fact that anything with access to the running etcd has full access to all secrets (okay, there are ACLs, but they're quite complex).

Reply on news.ycombinator.com