We ♥ ArgoCD
ArgoCD allows us to deploy our apps onto Kubernetes directly from our source control, GitHub.
We use all manner of tools here at Punk Security, this is the first of our new blog series where we delve into a few of them.
ArgoCD is a brilliant opensource project, readily available on GitHub and an absolute breeze to install into Kubernetes. It has plenty of features, some of which we will touch upon, but its aim is to keep your Kubernetes environment in synchronization with your source control so you can take advantage of those source control features. Before we delve into ArgoCD, lets recap those advantages of using source control.
Why do we want to deploy from source control?
Source control repositories have long been utilised by developers, but are now finding their place across the business and particularly amongst operations teams when they begin their Infrastructure As Code (IaC) journeys.
Source control brings a lot of value to our deployments as it allows us to ensure that all changes are auditable, and the git change history does this for us. When we need to change our environment, we modify our configuration in plaintext and then submit our change to source control, but before ArgoCD applies those changes they must be digitally signed and peer reviewed.
- Digital signatures
All of our amendments need to be digitally signed, giving us confidence that it really came from that team member, and provides non-repudiation to our audit logs. - Peer reviews
All of our changes must be reviewed by at least one other team member, ensuring they are well thought out and not malicious. This has been proven very effective in reducing the insider threat and the principle of dual control is heavily utilised in regulated industries such as Finance.
We also get a raft of other features out of the box; such as centralised access control, offline working, trivial rollback of changes and of course that full and transparent audit log.
What does ArgoCD bring to the table?
ArgoCD allows us to manage our workloads from a distance.
You can see this in our embedded image, where ArgoCD detects that a team member has requested a change to our Traefik deployment. As soon as this change is detected, ArgoCD takes the necessary actions to make our actual Traefik deployment match the new source controlled definition. In tandem with the power of Kubernetes, this is completely non-disruptive and will fail gracefully.
Alongside its primary function, it offers some extra value.
-
Prevents direct access to our Kubernetes environment
ArgoCD provides read-only visibility of our Kubernetes clusters to the team members that have permission to access it. This means our team members can see and debug the workloads they need to, without having access to our Kubernetes clusters. In fact, our Kubernetes clusters are not exposed to any team member directly. -
It deploys itself in exactly the same way
ArgoCD is deployed as a Kubernetes manifest, so we have it configured to deploy itself right from source control. This means we can control its configuration in exactly the same way we have already described, and it will keep itself aligned with that configuration.
What about Secrets?
ArgoCD deploys our secrets straight from source control too!
We use a system called sealed-secrets, although secret encryption and rotations are huge topics and sealed-secrets will not work for everyone.
Inside our Kubernetes clusters, an application generates and holds a private key which can decrypt secrets which have been specially encrypted using its public key. This public key is stored in our source control, just like everything else, and our teams members can encrypt their secrets and store them with their configurations. The use of public/private key means that team members can not decrypt all the other secrets in our source control unless they have access to the controller within the cluster.
Secret management can get tricky quickly, but it doesn’t have to be complicated. Reach out for assistance.
So what is happening in our animated image?
Simon has just deployed a change to our source control which changes a key configuration file for our Traefik ingress proxy configuration. The change is digitally signed, peer reviewed and merged into our actual configuration and ArgoCD takes over!
- The change is detected and the new configuration is compared against the existing
- ArgoCD moves to correct the difference, replacing the configuration
- The change in configuration triggers a redeployment of our first Traefik pod, Traefik-1
- Traefik-0 is now taking the full load for our ingress traffic
- Traefik-1 is now back online and has been checked to make sure its healthy
- Traefik-1 begins taking some of the load
- Treafik-0 now gets redeployed and picks up the new configuration
- Traefik-1 is now taking the full load for our ingress traffic
- Traefik-0 is now back online and has been checked to make sure its healthy
- Traefik-0 begins taking some of the load
- ArgoCD reports we are back in sync!
And that’s it! A fully automated, auditable and non-disruptive deployment of our change. 🔨🔧
