After the job runs, a secret named `ecr-credentials` should be created. Use this
name in your ECR ImageRepository resource manifest as the value for
`.spec.secretRef.name`.
Verify that `kustomize build .` works, then commit the directory to you control repo.
```yaml
spec:
secretRef:
name: ecr-credentials
```
Flux will apply the Deployment and it will use the workload identity for that Pod to regularly fetch ECR tokens into your configured `KUBE_SECRET` name.
Reference the `KUBE_SECRET` value from any `ImageRepository` objects for that ECR registry.
This example uses the `fluxcd/flux2` github archive as a remote base, but you may copy the [./manifests/integrations/registry-credentials-sync/aws]
folder into your own repository or use a git submodule to vendor it if preferred.
### GCP Container Registry
#### Using access token [short-lived]
!!! note "Workload Identity"
Please ensure that you enable workload identity for your cluster, create a GCP service account that has
access to the container registry and create an IAM policy binding between the GCP service account and
the Kubernetes service account so that the pods created by the cronjob can access GCP APIs and get the token.
Take a look at [this guide](https://cloud.google.com/kubernetes-engine/docs/how-to/workload-identity)
##### Pre-requisites
###### Workload Identity
Your GCP cluster will need [Workload Identity]
enabled.
###### Setting up authentication on GCP
Create a GCP service account to access the container registry
```bash
$ gcloud iam service-accounts create GSA_NAME
```
Create an IAM policy binding between the GCP service account and the Kubernetes service account.
The access token for GCR expires hourly.
Considering this limitation, one needs to ensure the credentials are being
refreshed before expiration so that the controller can rely on them for
authentication.
```bash
$ gcloud iam service-accounts add-iam-policy-binding \
##### Creating Deployment to refresh image-pull secret
The solution proposed is to create a cronjob that runs every 45 minutes which would
re-create the `docker-registry` secret using a new token.
Once we have workload identity enabled, GCP service account created, and IAM policy binding setup, we can create a deployment that frequently refreshes an image pull secret into our desired namespace.
Edit and save the following snippet to a file
`./clusters/my-cluster/gcr-sync.yaml`, commit and push it to git.
Create a directory in your control repository and save this `kustomization.yaml`:
iam.gke.io/gcp-service-account: <gsa-name>@<project-id>.iam.gserviceaccount.com # set the GCP service-account
```
After the job runs, a secret named `gcr-credentials` should be created. Use this
name in your GCR ImageRepository resource manifest as the value for
`.spec.secretRef.name`.
Verify that `kustomize build .` works, then commit the directory to you control repo.
```yaml
spec:
secretRef:
name: gcr-credentials
```
Flux will apply the Deployment and it will use the workload identity for that Pod to regularly fetch GCR tokens into your configured `KUBE_SECRET` name.
Reference the `KUBE_SECRET` value from any `ImageRepository` objects for that GCR registry.
This example uses the `fluxcd/flux2` github archive as a remote base, but you may copy the [./manifests/integrations/registry-credentials-sync/gcp]
folder into your own repository or use a git submodule to vendor it if preferred.
#### Using a JSON key [long-lived]
!!! warning "Less secure option"
From [Google documentation on authenticating container registry](https://cloud.google.com/container-registry/docs/advanced-authentication#json-key)
From [Google documentation on authenticating container registry][JSON key file Authentication method]
> A user-managed key-pair that you can use as a credential for a service account.
> Because the credential is long-lived, it is the least secure option of all the available authentication methods.
> When possible, use an access token or another available authentication method to reduce the risk of
> unauthorized access to your artifacts. If you must use a service account key,
> ensure that you follow best practices for managing credentials.
A Json key doesn't expire, so we don't need a cronjob,
we just need to create the secret and reference it in the ImagePolicy.
A JSON key doesn't expire, which makes the need for a deployment to refresh tokens redundant. All that is needed is to create the secret and reference it in the ImagePolicy.
Grant the service account the role of `Container Registry Service Agent`
so that it can access GCR and download the json file.
Follow steps 1-3 of the official GCP documentation regarding [JSON key file Authentication method]. This will guide you through creating a service account, and obtaining a JSON key file that can access GCR.
Then create a secret, encrypt it using [Mozilla SOPS](mozilla-sops.md)
or [Sealed Secrets](sealed-secrets.md) , commit and push the encypted file to git.
Generate a Kubernetes secret manifest with kubectl:
Encrypt it using [Mozilla SOPS] or [Sealed Secrets]. Once encrypted commit and push the encrypted file to git.
### Azure Container Registry
AKS clusters are not able to pull and run images from ACR by default.
Read [Integrating AKS /w ACR](https://docs.microsoft.com/en-us/azure/aks/cluster-container-registry-integration) as a potential pre-requisite
Read [Integrating AKS /w ACR] as a potential pre-requisite
before integrating Flux `ImageRepositories` with ACR.
Note that the resulting ImagePullSecret for Flux could also be specified by Pods within the same Namespace to pull and run ACR images as well.
#### Generating Tokens for Managed Identities [short-lived]
As a pre-requisite, your AKS cluster will need [AAD Pod Identity](../use-cases/azure.md#aad-pod-identity) installed.
As a pre-requisite, your AKS cluster will need [AAD Pod Identity] installed.
Once we have AAD Pod Identity installed, we can create a Deployment that frequently refreshes an image pull secret into
our desired Namespace.
@ -923,7 +828,7 @@ Verify that `kustomize build .` works, then commit the directory to you control
Flux will apply the Deployment and it will use the AAD managed identity for that Pod to regularly fetch ACR tokens into your configured `KUBE_SECRET` name.
Reference the `KUBE_SECRET` value from any `ImageRepository` objects for that ACR registry.
This example uses the `fluxcd/flux2` github archive as a remote base, but you may copy the [./manifests/integrations/registry-credentials-sync/azure](https://github.com/fluxcd/flux2/tree/main/manifests/integrations/registry-credentials-sync/azure)
This example uses the `fluxcd/flux2` github archive as a remote base, but you may copy the [./manifests/integrations/registry-credentials-sync/azure]
folder into your own repository or use a git submodule to vendor it if preferred.
#### Using Static Credentials [long-lived]
@ -931,15 +836,46 @@ folder into your own repository or use a git submodule to vendor it if preferred
!!! info
Using a static credential requires a Secrets management solution compatible with your GitOps workflow.
Follow the official Azure documentation for [Creating an Image Pull Secret for ACR](https://docs.microsoft.com/en-us/azure/container-registry/container-registry-auth-kubernetes).
Follow the official Azure documentation for [Creating an Image Pull Secret for ACR].
Instead of creating the Secret directly into your Kubernetes cluster, encrypt it using [Mozilla SOPS](mozilla-sops.md)
or [Sealed Secrets](sealed-secrets.md), then commit and push the encypted file to git.
Instead of creating the Secret directly into your Kubernetes cluster, encrypt it using [Mozilla SOPS]
or [Sealed Secrets], then commit and push the encrypted file to git.
This Secret should be in the same Namespace as your flux `ImageRepository` object.
Update the `ImageRepository.spec.secretRef` to point to it.
It is also possible to create [Repository Scoped Tokens](https://docs.microsoft.com/en-us/azure/container-registry/container-registry-repository-scoped-permissions).
It is also possible to create [Repository Scoped Tokens].
!!! warning
Repository Scoped Tokens are in preview and do have limitations.
<!-- Flux Docs -->
[AAD Pod Identity]: ../use-cases/azure.md#aad-pod-identity