4 ms·

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

33 points by lis 2y ago

sofixa 2y ago
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).
- MuffinFlavored 2y ago
  > 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?
  - sofixa 2y ago
    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...
- tjwjfasdflajsdf 2y ago
  > 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.
  - sofixa 2y ago
    > 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).
biimugan 2y ago
FWIW: The Helm chart has network policy in place: https://github.com/argoproj/argo-helm/blob/main/charts/argo-cd/templates/redis/networkpolicy.yaml 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
deleted 2y ago
[deleted]

33 points by lis 2y ago

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).

MuffinFlavored 2y ago
> 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?
- sofixa 2y ago
  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...
tjwjfasdflajsdf 2y ago
> 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.
- sofixa 2y ago
  > 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).

biimugan 2y ago

FWIW: The Helm chart has network policy in place: https://github.com/argoproj/argo-helm/blob/main/charts/argo-cd/templates/redis/networkpolicy.yaml 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

deleted 2y ago

[deleted]