blakepettersson
commented
1 year ago I think there's an upcoming feature in external-secrets that could be of interest here; external-secrets/external-secrets#1539.
If I understand it correctly, we'd be able to do something like this
apiVersion: generators.external-secrets.io/v1alpha1
kind: ECRAuthorizationToken # (or ACRAccessToken)
metadata:
name: "my-ecr"
spec:
# specify aws region (mandatory)
region: eu-west-1
# choose an authentication strategy
# if no auth strategy is defined it falls back to using
# credentials from the environment of the controller.
auth:
# option 2: IAM Roles for Service Accounts
# point to a service account that should be used
# that is configured for IAM Roles for Service Accounts (IRSA)
jwt:
serviceAccountRef:
name: "oci-token-sync"
---
apiVersion: external-secrets.io/v1beta1
kind: ExternalSecret
metadata:
name: "argo-helm"
spec:
refreshInterval: "30m"
target:
name: argo-helm
# Specify a blueprint for the resulting Kind=Secret
template:
metadata:
labels:
argocd.argoproj.io/secret-type: repository
dataFrom:
- sourceRef:
generatorRef:
apiVersion: generators.external-secrets.io/v1alpha1
kind: ECRAuthorizationToken
name: "my-ecr"
alexef
jacek-jablonski
nahum-landa
ahaw023
hyelavarthi
rohit-dimagi
abatesbot
burakovsky
konsloiz
joshmue
I could not find an existing GH issue covering that, so here we go. If you want, I could take a look on how to implement this.
Summary
Implement option to fetch repository credentials at runtime.
Motivation
For cluster access, ArgoCD already offers setting
ExecProviderConfigto fetch cluster credentials dynamically using a Kubernetes credential plugin.This feature makes it possible to rely on a cloud's IAM system instead of relying on manually maintained secrets.
That is great, as it has big advantages in terms of security as well as in terms of maintainability.
E.g. one may use... (I did not use the latter two yet)
aws eks get-tokenfor Amazon EKSgke-gcloud-auth-pluginfor Google GKEHowever, for (private) repositories, it is still required to manage secrets manually.
Proposal
Implement support for fetching repository credentials dynamically - akin to the
ExecProviderConfigfunctionality for clusters.This most likely has to be implemented separately for Git repositories and Helm repositories.
For Helm repositories
Use case: Serve (OCI) Helm Charts from a managed container registry.
Add configuration section (akin to
ExecProviderConfigfor clusters) allowing to specify a command/script returning username, password/token and optionally time of expiry for a specific container registry.As far as I can tell, most of the heavy lifting is already done by most big cloud providers (I did not use the latter two yet):
az acr login --expose-tokenaws ecr get-authorization-tokengcloud auth print-access-tokenWhile the configuration and input/output of Kubernetes credential plugins are well defined using K8s-style API groups and versions, there is no such thing for registries, AFAIK.
So it may be necessary to define some sort of such contract and wrap execution of the platform tools with some shell script harmonizing input/output. For thoughts on how such contract may look like, see below.
For Git repositories
Unfortunately, I have no idea how to implement this in a good-enough fashion. It's not as easy like it is for Helm repositories, as Git providers usually do not accept tokens issued by a cloud IAM system.
Appendix
Example API's
In its simplest form:
Configuration:
Input via environment variable: None
Output via stdout:
Mimic cluster ExecProviderConfig style:
Configuration:
Input: Like K8s via environment variable.
Output: Like K8s via stdout.