flowchart TB
subgraph ns1 ["<br><br><br>
namespace 1"]
a1("fa:fa-key ECR secret
kubernetes.io/dockerconfigjson
")
end
subgraph ns2 ["<br><br><br>
namespace 2"]
b1("fa:fa-key ECR secret
kubernetes.io/dockerconfigjson
")
end
subgraph ns3 ["<br><br><br>
namespace 3"]
c1("fa:fa-key ECR secret
kubernetes.io/dockerconfigjson
")
end
operator("fa:fa-wrench kube-ecr-secrets-operator")
operator --> |"fa:fa-rotate-right rotate every 12h"|a1
operator --> |"fa:fa-rotate-right rotate every 12h"|b1
operator --> |"fa:fa-rotate-right rotate every 12h"|c1
Kubernetes Operator for managing AWS ECR (Elastic Container Registry) secrets cluster wide. ECR docker credentials expire every 12 hours, and need to be refreshed whenever you need to deploy. This operator's goal is to help manage the ECR image pull secrets by refreshing them periodically. It introduces the AWSECRCredentials
cluster scoped object that:
- creates a docker credential secret in all the specified namespaces upon creation
- Once the secrets are created, the operator takes care of refreshing them periodically (every 12h)
Here is an example of the AWSECRCredentials
specification:
apiVersion: aws.zakariaamine.com/v1alpha1
kind: AWSECRCredential
metadata:
name: my-ecr-credentials
spec:
awsAccess:
accessKeyId: YOUR_ACCESS_KEY_ID
secretAccessKey: YOUR_SECRET_ACCESS_KEY
region: THE_ECR_REGION
secretName: ecr-login
namespaces:
- ns1
- ns2
- ns3
- ns4
The operator expects cert-manager to be present in the cluster, since it makes use of Issuer
and Certificate
kinds. Because there are some gotchas related to having cert-manager as a subchart(See this issue and this issue for more details ), kube-ecr-secrets-operator leaves the responsibility to the chart consumer to install it. Installation instructions can be found in the official docs
The operator can be installed using helm:
helm repo add zakariaamine https://zak905.github.io/kube-ecr-secrets-operator/repo-helm
helm repo update
helm install --create-namespace kube-ecr-secrets-operator zakariaamine/kube-ecr-secrets-operator -n kube-ecr-secrets-operator-system
Once the chart is installed, AWSECRCredentials
objects can be created.
It is, off course, highly recommended to limit the permissions of the IAM user represented by the credentials to ECR only.
The AWSECRCredentials
CRD definition is installed with the helm chart using the crds folder. However, a known shortcoming of using helm to install CRDs is the inability to update the CRDs (if there is a change) on subsequent chart upgrades. To overcome the shortcoming, one of the following solutions can help:
- The chart can be uninstalled and installed when there is a new release with a CRD change.
- The CRDs can be installed using
kubectl
as a first stepkubectl apply -f https://raw.githubusercontent.com/zak905/kube-ecr-secrets-operator/master/chart/crds/AWSECRCredentials.yaml
, and then the chart can be installed with the--skip-crds
flag.
In case an unexpected behavior is observed, the first step for troubleshooting is to inspect the status
of AWSECRCredentials
object: kubectl get awsecrcredentials the-name-of-the-object
. The status
shows informations about the current state of the object. For example:
status:
conditions:
- lastTransitionTime: "2023-10-04T20:45:52Z"
message: 'AWS ECR secret with type kubernetes.io/dockerconfigjson have been
created/updated successfully in namespaces: [ns1] next update at: 2023-10-05
08:45:52.269 +0000 UTC'
reason: SecretsUpdated
status: "True"
type: Ready
The status
provides enough information to identify potential issues. Additionally, the contoller emits Kubernetes events whenever an action is taken. The following event can be observed: SecretCreationSuccess
, SecretUpdateSuccess
, CreateSecretError
, UpdateSecretError
.
The logs of the contoller pod can also help: kubectl logs -l app.kubernetes.io/name=kube-ecr-secrets-operator -n kube-ecr-secrets-operator-system
- Depends on cert-manager (for now)
- An
AWSECRCredentials
object can manage only a single AWS region, which means that if you have multiple registries in different regions, you need to create anAWSECRCredentials
for each.
To run tests, the following environment variables need to set AWS_ACCESS_KEY_ID
, AWS_SECRET_ACCESS_KEY
, AWS_REGION
in the terminal from which the tests are run. Afterwards, the tests can be run using: make test
- attempt to remove the dependency on
cert-manager
. Since TLS is only for internal usage, and a self signed certificate is enough, a certificate can be manually created by the operator or by a job when the chart is installed. The certificate can have an expiry date very far ahead in the future so that it does not need to be renewed. - making
AWSECRCredentials
manage registries for several AWS regions