Configure a kubelet image credential provider [page]deterministic
Starting from Kubernetes v1.20, the kubelet can dynamically retrieve credentials for a container image registry using exec plugins. The kubelet and the exec plugin communicate through stdio (stdin, stdout, and stderr) using Kubernetes versioned APIs. These plugins allow the kubelet to request credentials for a container registry dynamically as opposed to storing static credentials on disk. For example, the plugin may talk to a local metadata server to retrieve short-lived credentials for an image that is being pulled by the kubelet.
You may be interested in using this capability if any of the below are true:
* API calls to a cloud provider service are required to retrieve authentication information for a registry. * Credentials have short expiration times and requesting new credentials frequently is required. * Storing registry credentials on disk or in imagePullSecrets is not acceptable.
This guide demonstrates how to configure the kubelet's image credential provider plugin mechanism.
## Service Account Token for Image Pulls
Starting from Kubernetes v1.33, the kubelet can be configured to send a service account token bound to the pod for which the image pull is being performed to the credential provider plugin.
This allows the plugin to exchange the token for credentials to access the image registry.
To enable this feature, the `KubeletServiceAccountTokenForCredentialProviders` feature gate must be enabled on the kubelet, and the `tokenAttributes` field must be set in the `CredentialProviderConfig` file for the plugin.
The `tokenAttributes` field contains information about the service account token that will be passed to the plugin, including the intended audience for the token and whether the plugin requires the pod to have a service account.
Using service account token credentials can enable the following use-cases:
* Avoid needing a kubelet/node-based identity to pull images from a registry. * Allow workloads to pull images based on their own runtime identity without long-lived/persisted secrets.
##
* You need a Kubernetes cluster with nodes that support kubelet credential provider plugins. This support is available in Kubernetes ; Kubernetes v1.24 and v1.25 included this as a beta feature, enabled by default. * If you are configuring a credential provider plugin that requires the service account token, you need a Kubernetes cluster with nodes running Kubernetes v1.33 or later and the `KubeletServiceAccountTokenForCredentialProviders` feature gate enabled on the kubelet. * A working implementation of a credential provider exec plugin. You can build your own plugin or use one provided by cloud providers.
## Installing Plugins on Nodes
A credential provider plugin is an executable binary that will be run by the kubelet. Ensure that the plugin binary exists on every node in your cluster and stored in a known directory. The directory will be required later when configuring kubelet flags.
## Configuring the Kubelet
In order to use this feature, the kubelet expects two flags to be set:
* `--image-credential-provider-config` - the path to the credential provider plugin config file. * `--image-credential-provider-bin-dir` - the path to the directory where credential provider plugin binaries are located.
### Configure a kubelet credential provider
The configuration file passed into `--image-credential-provider-config` is read by the kubelet to determine which exec plugins should be invoked for which container images. Here's an example configuration file you may end up using if you are using the [ECR-based plugin](https://github.com/kubernetes/cloud-provider-aws/tree/master/cmd/ecr-credential-provider):
```yaml apiVersion: kubelet.config.k8s.io/v1 kind: CredentialProviderConfig # providers is a list of credential provider helper plugins that will be enabled by the kubelet. # Multiple providers may match against a single image, in which case credentials # from all providers will be returned to the ku …(trimmed)