r/ArgoCD

▲ 18 r/ArgoCD

GitOps and Secrets

When discussing secrets management in Argo CD, there are two important questions every team should ask:

  • Should changing a secret require an Argo CD sync?
  • Should your secrets solution be coupled to Argo CD?

The answer to both is: definitely not.

Tomorrow on Argo Unpacked we’re having an open discussion about secrets management best practices in Argo CD: (https://www.linkedin.com/events/7454090384584118272)

  • different approaches and tradeoffs
  • decoupling secrets from deployment workflows
  • operational considerations
  • what works well in real environments (and what usually doesn’t)

Curious how others here think about this too:
How are you handling secrets with Argo CD today?

reddit.com
u/Physical_Growth7566 — 4 days ago
▲ 90 r/ArgoCD+1 crossposts

A read-only ArgoCD user can extract every Kubernetes Secret in your cluster.

That's the GHSA-3v3m-wc6v-x4x3, a CVSS 9.6 Critical vulnerability affecting ArgoCD versions 3.2.0 through 3.3.8 (GitHub Advisory, 2026). No admin access. No special tooling. One annotation and a diff request.

The vulnerability lives in ArgoCD's ServerSideDiff feature. When an Application has the IncludeMutationWebhook=true annotation, the diff endpoint returns raw Kubernetes API responses that include the full .data contents of Secrets.

The root cause is a single missing function call: hideSecretData() was wired into every other diff code path but was never added to the ServerSideDiff handler.

u/Kooky_Comparison3225 — 12 days ago
▲ 28 r/ArgoCD+7 crossposts

I added dedicated OpenShift support to KubeShark.

Mini recap:

KubeShark is my Kubernetes skill for Claude Code and Codex.

It helps AI agents generate, review, and refactor Kubernetes manifests without falling into the usual LLM traps: missing security contexts, deprecated API versions, broken selectors, wildcard RBAC, unsafe probes, missing resource requests, and rollout configs that look okay but fail under real traffic.

The important part is that KubeShark is failure-mode-first. It does not just tell the model “write good Kubernetes”. It forces the model to reason about what can go wrong before it generates YAML, and then return validation and rollback guidance as part of the answer.

That matters a lot with Kubernetes, because many bad manifests are accepted by the API server and only fail later at runtime.

Repo: https://github.com/LukasNiessen/kubernetes-skill

---

Now what’s new:

KubeShark now has special dedicated OpenShift support.

When the task involves OpenShift, OKD, ROSA, ARO, Routes, SCCs, OLM, ImageStreams, or oc, KubeShark switches into OpenShift-aware guidance.

This matters because OpenShift is Kubernetes, but with important platform behavior that generic Kubernetes YAML often ignores.

Common LLM mistakes include:

  • hardcoding runAsUser: 1000
  • assuming root-capable images will run
  • telling users to edit default SCCs
  • granting anyuid or privileged too broadly
  • using Ingress-controller annotations on OpenShift Routes
  • forgetting to validate with oc

Example guidance KubeShark now keeps in mind:

apiVersion: route.openshift.io/v1
kind: Route
metadata:
  name: app
spec:
  to:
    kind: Service
    name: app
  tls:
    termination: edge

It also knows to treat OpenShift Routes, SCCs, arbitrary UID containers, and OLM-managed resources as first-class concerns.

So instead of generic Kubernetes advice, you get OpenShift-aware manifest generation and review.

u/trolleid — 11 days ago