Apply Flux v1 configurations at-scale using Azure Policy
You can use Azure Policy to apply Flux v1 configurations (
Microsoft.KubernetesConfiguration/sourceControlConfigurations resource type) at scale on Azure Arc-enabled Kubernetes clusters (
This article is for GitOps with Flux v1. GitOps with Flux v2 is now available for Azure Arc-enabled Kubernetes and Azure Kubernetes Service (AKS) clusters; go to the article for using policy with Flux v2. Eventually Azure will stop supporting GitOps with Flux v1, so we recommend migrating to Flux v2 as soon as possible.
To use Azure Policy, select a built-in GitOps policy definition and create a policy assignment. When creating the policy assignment:
- Set the scope for the assignment.
- The scope will be all resource groups in a subscription or management group or specific resource groups.
- Set the parameters for the GitOps configuration that will be created.
Once the assignment is created, the Azure Policy engine identifies all Azure Arc-enabled Kubernetes clusters located within the scope and applies the GitOps configuration to each cluster.
To enable separation of concerns, you can create multiple policy assignments, each with a different GitOps configuration pointing to a different Git repo. For example, one repo may be used by cluster admins and other repositories may be used by application teams.
There are built-in policy definitions for these scenarios:
- Public repo or private repo with SSH keys created by Flux:
Configure Kubernetes clusters with specified GitOps configuration using no secrets
- Private repo with user-provided SSH keys:
Configure Kubernetes clusters with specified GitOps configuration using SSH secrets
- Private repo with user-provided HTTPS keys:
Configure Kubernetes clusters with specified GitOps configuration using HTTPS secrets
Verify you have
Microsoft.Authorization/policyAssignments/write permissions on the scope (subscription or resource group) where you'll create this policy assignment.
Create a policy assignment
- In the Azure portal, navigate to Policy.
- In the Authoring section of the sidebar, select Definitions.
- In the "Kubernetes" category, choose the "Configure Kubernetes clusters with specified GitOps configuration using no secrets" built-in policy definition.
- Select Assign.
- Set the Scope to the management group, subscription, or resource group to which the policy assignment will apply.
- If you want to exclude any resources from the policy assignment scope, set Exclusions.
- Give the policy assignment an easily identifiable Name and Description.
- Ensure Policy enforcement is set to Enabled.
- Select Next.
- Set the parameter values to be used while creating the
- For more information about parameters, see the tutorial on deploying GitOps configurations.
- Select Next.
- Enable Create a remediation task.
- Verify Create a managed identity is checked, and that the identity will have Contributor permissions.
- For more information, see the Create a policy assignment quickstart and the Remediate non-compliant resources with Azure Policy article.
- Select Review + create.
After creating the policy assignment, the configuration is applied to new Azure Arc-enabled Kubernetes clusters created within the scope of policy assignment.
For existing clusters, you may need to manually run a remediation task. This task typically takes 10 to 20 minutes for the policy assignment to take effect.
Verify a policy assignment
- In the Azure portal, navigate to one of your Azure Arc-enabled Kubernetes clusters.
- In the Settings section of the sidebar, select Policies.
- In the list, you should see the policy assignment that you created earlier with the Compliance state set as Compliant.
- In the Settings section of the sidebar, select GitOps.
- In the configurations list, you should see the configuration created by the policy assignment.
- In the Kubernetes resources section of the sidebar, select Namespaces and Workloads.
- You should see the namespace and artifacts that were created by the Flux configuration.
- You should see the objects described by the manifests in the Git repo deployed on the cluster.