helm: Allow for iRSA

[jwitko]

The helm chart currently only allows for hard-coded environment variable based AWS IAM access key and secret key input. It does not allow for not-specifying these and letting iRSA handle it via the kubernetes service account.

[prometherion]

I'm not an AWS expert here, please, correct me if I'm wrong, and if I'm missing the context that should be about the following environment variables:

kamaji-etcd/charts/kamaji-etcd/values.yaml

Lines 100 to 103 in 0536a54

	valueFrom: {}
	# secretKeyRef:
	# key: access_key
	# name: minio-key

kamaji-etcd/charts/kamaji-etcd/values.yaml

Lines 105 to 110 in 0536a54

	secretKey:
	value: ""
	valueFrom: {}
	# secretKeyRef:
	# key: secret_key
	# name: minio-key

If I understood correctly, we should make these ones optional to let the S3 client interact using the Kubernetes Service Account.

[jwitko]

Yes and also changing the conditionals around these to not be supplied:

kamaji-etcd/charts/kamaji-etcd/templates/etcd_cronjob_backup.yaml

Lines 76 to 89 in 0536a54

	- name: S3_ACCESS_KEY
	{{- if .Values.backup.s3.accessKey.value }}
	value: {{ .Values.backup.s3.accessKey.value | quote }}
	{{- else }}
	valueFrom:
	{{- toYaml .Values.backup.s3.accessKey.valueFrom | nindent 16 }}
	{{- end }}
	- name: S3_SECRET_KEY
	{{- if .Values.backup.s3.secretKey.value }}
	value: {{ .Values.backup.s3.secretKey.value | quote }}
	{{- else }}
	valueFrom:
	{{- toYaml .Values.backup.s3.secretKey.valueFrom | nindent 16 }}
	{{- end }}

[bsctl]

@jwitko @prometherion honestly, I would to move the backup script away from this chart and leave this duty to the datastore (human) operator as there are several ways to backup etcd in different environments. This issue is exactly the reason. Please note, this chart is not an etcd operator, so it should not mimic it. The etcd community is working to a new etcd operator and we'll switch to that once they done.

Anyway, we can leave the backup script in this repo as simple tool (as the restore one) for basic usage, leaving more
sophisticated users to implement their own backup strategy.

[bsctl]

@kvaps for commenting

[kvaps]

I don't mind, but we already switched to using
https://github.com/aenix-io/etcd-operator

Currently it already implements the same functionality as this Helm chart, except periodic defragmentation and backups which can simple done using cronjobs.

We're working on submitting this project to sig-etcd.
The working group already established:

• etcd operator working group kubernetes/community#7917

This week we had a first meeting with SIGs, where we discovered features needed by the community to prepare the roadmap.

[bsctl]

closed by #70