CODEWITHSUNDEEP
azurekubernetesazure-aksgitopsfluxcd
The Senator
The Senator

Reputation: 5401

When using Flux2 with Azure Kubernetes Service how to I authorise the ImageRespository YAML correctly (workload/kubelet)?

I've been working with Flux2 in AKS for a few months now and am slowly progressing to some of the more interesting features. This week I'm trying to set up an ImageRepository which can see when my latest image has been updated and pull the latest in to my Dev Cluster. My flux system has been setup using Bicep scripts and I have enabled the two additional controllers for ImageRepository and Image scanning.

Documentation wise, it is suggested that the kubelet service principal is the only thing that needs to have the AcrPull role (note that AKS can happily pull images) but I've found this not to be the case when reviewing the logs. Therefore I have embarked on a journey to find out what it is that needs to be done to enable this interesting feature.

Recently, I have also enabled workload-identity in AKS, I have also added a user managed identity with ferederated credentials and have attempted the suggested patch kustomization that is recommended for granting the service accounts the necessary workload identity which looks like this:

apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
resources:
  - gotk-components.yaml
  - gotk-sync.yaml
patches:
  - patch: |-
      apiVersion: v1
      kind: ServiceAccount
      metadata:
        name: image-reflector-controller
        namespace: flux-system
        annotations:
          azure.workload.identity/client-id: <AZURE_CLIENT_ID>
        labels:
          azure.workload.identity/use: "true"      
  - patch: |-
      apiVersion: apps/v1
      kind: Deployment
      metadata:
        name: image-reflector-controller
        namespace: flux-system
        labels:
          azure.workload.identity/use: "true"
      spec:
        template:
          metadata:
            labels:
              azure.workload.identity/use: "true"

I have tried applying this as a kustomization but when I do so, I have no idea where these magical 'gotk-components.yaml' and 'gotk-sync.yaml' files are meant to come from as this is a patch. I tried removing those and then got told that there was no matching service to be patched (the image-reflector-controller) cannot find a matching service account

no matches for Id ServiceAccount.v1.[noGrp]/image-reflector-controller.flux-system; failed to find unique target for patch ServiceAccount.v1.[noGrp]/image-reflector-controller.flux-system

Basically I'm slightly lost as to how this patching system is working (I'm doing it as a nested kustomization within an existing kustomization) and if necessary where these gotk prefixed components come from. The referenced instructions are here https://fluxcd.io/flux/components/image/imagerepositories/#authentication and I'm working through the Azure Workload Identity patch section.

The necessary underlying controllers appear to be enabled, but I see authentication issues with my ImageRepository yaml. Is this the right way to do it? Or can I set a ServiceAccount directly on the ImageRepository? (I've tried this as well and couldn't get that to work either).

Upvotes: 0

Views: 476

Answers (1)

MartinW
MartinW

Reputation: 11

I have this error when I didn't add option :

flux bootstrap git [...] --components-extra=image-reflector-controller,image-automation-controller

To confirm, you should find in gotk-components.yaml somthing similar to :

---
apiVersion: v1
kind: ServiceAccount
metadata:
  labels:
    app.kubernetes.io/component: image-reflector-controller
    app.kubernetes.io/instance: flux-system
    app.kubernetes.io/part-of: flux
    app.kubernetes.io/version: v2.1.2
  name: image-reflector-controller
  namespace: flux-system

Upvotes: 1

Related Questions