Interested in making Kubernetes deployments more secure AND automated? If so, keep reading. :)
FluxCD, commonly just called Flux, is an open-source and cloud-native Continuous Delivery (CD) and GitOps tool designed to automate deployments to Kubernetes.
And in this post, you'll learn how to install and configure Flux to automate the deployment of patched and signed containers images.
In the graphic above, you'll notice that the secure pipeline has two phases; build and deploy. This post focuses on automating the deploy phase, but that requires you already have the Azure infrastructure setup and a GitHub Action Workflow configured to handle the build or CI portion of the pipeline. So, you'll need to do some prerequisite work to follow along.
Once you've completed the setup, you should have a working Azure environment with two signed container images for the Azure Voting app hosted in ACR, which is the necessary starting point for this post.
Note: The setup for this is heavy, even though it's automated. So, if you'd like just continue reading and learn how Flux can be used to automate Kubernetes deployments. :)
Flux is a GitOps tool and every GitOps tool needs a Git repository. To get the repo setup follow these steps:
- Fork secure-supply-chain-on-aks repo.
- Generate a token for Flux to access the repo. Here's a great clip to walk you through those steps.
- Clone the repo to your local machine with,
- Switch to the GitOps branch with
git checkout GitOps
In order to get FluxCD working on the cluster, you're going to have to first deploy FluxCD operator to the cluster. Luckily, the FluxCLI makes this super easy.
Here's what you need to do:
- Install the FluxCLI
Export the environment variables
export GITHUB_TOKEN=<your-token> export GITHUB_USER=<your-username>
flux bootstrap github \ --components-extra=image-reflector-controller, image-automation-controller \ --owner=$GITHUB_USER \ --repository=secure-supply-chain-on-aks \ --branch=copaGitOps \ --path=clusters/my-cluster \ --read-write-key \ --personal
Once this command completes, issue a
git pull command and you'll notice a new directory call
cluster. What the
flux bootstrap command did was commit all the necessary manifests to deploy Flux to your cluster.
Now that Flux has been deployed the next thing you need to do is create a source.
Flux supports several source options, but in this post, you'll use
git as the source.
Run the following command to create the flux source manifest file:
flux create secret git azure-voting \ --url=https://github.com/duffney/secure-supply-chain-on-aks \ --username=$GITHUB_USER \ --password=$GITHUB_TOKEN flux create source git azure-voting \ --url=https://github.com/duffney/secure-supply-chain-on-aks/ \ --branch=GitOps \ --interval=1m \ --secret-ref azure-voting \ --export > ./clusters/my-cluster/azure-voting-source.yaml
In the above, command the FluxCLI was used to generate a Kubernetes manifest file that configures the desired Git repository as a source within the Flux system. What this essentially does is makes Flux aware of the Git repository that you want to monitor for changes.
Run the following command to view all Flux Sources that use Git:
flux get sources git
Didn't see your repo listed⁉️ Well, that's the Flux system is looking at your GitHub repository for its changes! Flux itself uses GitOps to manage its deployments. 😅
Run the following commands to push the new Git source to the Flux system:
git add -A && git commit -m "Add azure-votiong-app GitRepository" git push
flux get sources git again and you'll see the newly created source. Next, you'll configure which files within that repository Flux will care about.
To use Flux with your Kubernetes deployments they need to be packaged somehow and one of the ways to do that is to use the popular resource configuration management tool, Kustomize.
Kustomize gives you the ability to create a single file, called a
Kustmization.yaml that bundles your deployment. It's that bundle, so to speak, that Flux uses to determine which files to monitor for changes in your GitRepo.
If you're following along, but using your own appliaction you can create a Kustomization.yaml file by running
kustomize create --autodetect within the directory that contains the manifests.
But just having a
Kustomization.yaml file within your repository isn't enough, Flux needs to be made aware of it and how you'd like it to run the deployment.
So, to take care of that create a Flux Kustomization resources with the following command:
flux create kustomization azure-voting \ --source=azure-voting \ --path="./manifests" \ --prune=true \ --wait=true \ --interval=1m \ --retry-interval=2m \ --health-check-timeout=3m \ --export > ./clusters/my-cluster/azure-voting-kustomization.yaml
Oh, don't forget to push these changes to your repo too. :)
git add -A && git commit -m "Add azure-voting-app Kustomization" git push
Given the intervals set in the Kustomization and Source it shouldn't take long for Flux to deploy the Azure-Voting-App to the AKS cluster, but if you're eager to see what's going on you can run the following commands:
Get the public IP address of the webapp with
kubectl get ingress, and put it into a browsers and you should see the image below.
This post picked up after the build phase of the secure supply chain that is responsible for scanning, patching, and signing container images. If you'd like to learn more about that check out the following resources:
- Securing container deployments on Azure Kubernetes Service with open-source tools | BRK264H
To dive deeper into GitOps, I highly recommend the follow articles written by my teammates:
- Just Enough Git for GitOps
- What Really is GitOps?
- Git going with GitOps on AKS: A Step-by-Step Guide using FluxCD AKS Extension
- Automating Image Updates on AKS: A Step-by-Step Guide using open source FluxCD