Managing Argo CD Secrets with Akeyless

Welcome to our Akeyless on Akeyless series, where we discuss how the DevOps team at Akeyless uses Akeyless to take secrets management to the next level. In this article, we discuss how to securely manage Argo CD Secrets.

---

When speaking with Lior Hasson, the Head of DevOps at Akeyless, we uncovered an Akeyless use case that got him particularly excited: the integration with External Secrets Operator to securely handle Kubernetes secrets using GitOps and Argo CD. 

In this post, we will look into which options the Akeyless DevOps team considered, and, ultimately, what solution they landed on to secure Kubernetes secrets in a GitOps workflow using Argo CD and the External Secrets Operator.

The Problem with Secrets Management Using GitOps

GitOps uses Git as the single source of truth to deploy changes, and ensures the system is always in the desired state.

Using Git as the source of truth can have a variety of benefits:

• There is better compliance and auditability, because any changes to infrastructure are tracked in version control.
• The system stays more consistent over time, as GitOps tools like Argo CD constantly compare the system to the source of truth, making sure that any erroneous changes are self-healed.
• Deployment is faster because delivery and deployment is automated, avoiding manual mistakes and integrating seamlessly with CI/CD pipeline deployments.

Despite all these benefits, there’s one critical question that arises when infrastructure is maintained with version control: What about secrets?

In Kubernetes, containers need to both securely store and access secrets in order to function. The approach with least resistance is to store secrets in the code itself. However, this isn’t the best approach, as hard-coding secrets in code increases risk of a breach. In using Argo CD, a popular tool for implementing GitOps, Lior knew he had to find a better approach to handle secrets within Kubernetes.

At first, the team handled secrets by manually encrypting and decrypting secrets. However, this quickly grew unsustainable as the Kubernetes infrastructure grew. They looked into other solutions for handling Kubernetes secrets, like Sealed Secrets, but found that it didn’t have the performance and flexibility necessary at scale.

Ultimately, Lior and his team went with the Kubernetes External Secrets Operator because it was flexible, and allowed the team to integrate Akeyless with ArgoCD.

Managing ArgoCD Secrets with the Kubernetes External Secrets Operator

The Kubernetes External Secrets Operator (ESO) enables a Kubernetes cluster to securely store and manage sensitive data outside of it while making the data available to applications running within it. It integrates with secret management systems like Akeyless.

This is how the External Secrets Operator (ESO) works in conjunction with Akeyless and ArgoCD:

As discussed previously, Argo CD is the GitOps tool that monitors for any changes in Git. It then implements the desired application state, which is defined in Kubernetes manifests. In the case pictured above, Argo CD syncs the ExternalSecret manifest from a Git repo to create an ExternalSecret resource inside the Kubernetes cluster (1).

The ESO Controller inspects the configuration of the synced ExternalSecret to determine which SecretStore to use and the path in the external API (Secrets Manager e.g. Vault) where the secret is located (2).

In the below example of a ExternalSecret manifest, you can see that it points to the akeyless-secret-store under secretStoreRef. It also designates a path that tells the ESO Controller where to access a particular secret within Akeyless.

In (3), the Controller then queries the SecretStore for the credentials required to access the external API. The SecretStore is another manifest that determines how to access the secret manager of your choice. In this case, it’s Akeyless. 

In the below code example of a SecretStore manifest, you can see the name of the defined SecretStore is akeyless-secret-store. This is what the ExternalSecret snippet above is referring to. You can see the details that allow the ESO Controller to access Akeyless in the secretRef section. 

Now, the ESO Controller has all the ingredients necessary to get the secret it needs, including:

1. How to access the external secret manager
2. Where to find the secret

With both ingredients, you can see in (4) that the ESO fetches the secret(s) from the secrets manager at the path declared in the ExternalSecret.

Finally, in (5), the ESO Controller creates and syncs an actual Kubernetes secret resource inside the cluster.

Syncing Argo CD Secrets with Akeyless

If you choose, you can configure your Argo CD app to automatically sync with your ExternalSecret manifests. Argo CD will pick up these changes and reflect them in the cluster. To create new Kubernetes secrets, push additional ExternalSecret manifests to the repository path Argo CD is monitoring.

The ESO controller can monitor Akeyless at regular intervals for changes in secret values, updating the corresponding cluster secret values. The ESO controller will check for updates at the interval you set in the ExternalSecret manifest.

For a step-by-step on how to use the External Secrets Operator with Akeyless, check out our online documentation.

About Akeyless

Akeyless is a born-in-the-cloud secrets management platform for enterprise DevOps teams. Easy to set up and scale, it has integrations for every use case and comprehensive logs for troubleshooting and auditability. 

Ready to learn more about Akeyless? Get a custom demo today at akeyless.io.