Skip to main content
Plerion Collector Manager needs access to private registries to scan the private images deployed in the Kubernetes cluster.

AWS Elastic Container Registry (ECR)

1. Create an IAM OIDC identity provider for your cluster.

2. Override the existing plerion-collector-manager service account and attach the IAM policy to grant it permission to pull images from the ECR.

Please note that this command requires access to both AWS IAM and the Kubernetes cluster
  • AWS Access: The user executing the eksctl command must have sufficient IAM permissions to create and manage IAM roles, as well as to attach policies like AmazonEC2ContainerRegistryReadOnly.
  • Kubernetes Access: The same user must also have the necessary Kubernetes permissions (e.g., via kubectl) to manage service accounts within the specified Kubernetes namespace.

Azure Container Registry (ACR)

1. Prerequisites

Please ensure the following prerequisites are met before using the operator:
  • The official steps for setting up Workload Identity on AKS can be found here.
  • Managed clusters or self-managed clusters installed, see documentation
  • Mutating admission webhook installed, see documentation
  • plerion-collector-manager Upgraded to latest version (v1.1.7 or newer), see Upgrade/Rollback.

2. Export the required variables in environment

3. Retrieve OIDC issuer url

See azure documentation for retrieving OIDC issue url. For AKS cluster use following command.

4. Create managed identity.

5. Assign AcrPull IAM permissions to managed identity.

6. Create a Kubernetes service account.

7. Create federated identity.

8. Update plerion-collector-manager ServiceAccount to include workload identity annotations.

9. Update plerion-collector-manager to use azWorkloadIdentity

10. Update service account for plerion-collector-manager.

Registries the cluster already has credentials for

The sections above give the collector a cloud identity of its own for the cloud’s registry. A cluster also holds credentials of its own: Kubernetes pull secrets (kubernetes.io/dockerconfigjson or kubernetes.io/dockercfg). The collector can pull with those too, from collector chart v1.2.9 on. Name the secrets as namespace/name in the chart value collector.registry.pullSecrets. The chart grants the collector read access to each one, and the scanner authenticates with them when it pulls an image.
On OpenShift this is how the platform’s own images scan: they are named from quay.io/openshift-release-dev but pulled through the cluster’s image mirror sets (ImageDigestMirrorSet, ImageTagMirrorSet, ImageContentSourcePolicy) with the credentials in openshift-config/pull-secret. With that secret named, the collector follows the same mirrors (collector.registry.followClusterMirrors, on by default) and pulls the platform images the way the nodes do. Without it, the platform images are reported as failed scans and your own workload images scan as before. A private image whose registry is covered by neither a cloud identity nor a named pull secret is reported as a failed scan for that workload; public images pull anonymously as before.