BUG REPORT
Version of Helm and Kubernetes:
Helm v2.11.0
Kubernetes 1.10 (AWS EKS)
Which chart:
What happened:
Enabling AWS SSM in the concourse-values.yaml with the configurations below will result in an error.
concourse:
web:
awsSsm:
# Enable the use of AWS SSM.
#
enabled: true
# AWS region to use when reading from SSM
#
region: "us-east-1"
or
concourse:
web:
awsSsm:
# Enable the use of AWS SSM.
#
enabled: true
Both configurations will result in the same error:
$ helm install --name concourse --namespace cicd stable/concourse -f configs/concourse-values.yaml
Error: render error in "concourse/templates/web-deployment.yaml": template: concourse/templates/web-deployment.yaml:274:26: executing "concourse/templates/web-deployment.yaml" at <.Values.concoures.we...>: can't evaluate field web in type interface {}
What you expected to happen:
I can deploy concourse using AWS SSM to store parameters and secrets.
How to reproduce it (as minimally and precisely as possible):
See What happened for more details.
Anything else we need to know:
This seems to be a regression in the after bumping Concourse up to 4.2.1: https://github.com/helm/charts/commit/263bc80322056455c7120b51f1992a40667ec686
I've also experienced issues that are very likely related to this, but trying to get concourse to consume AWS Secrets Manager. It appears that the template confuses Secrets Manager and Systems Manager resulting in a bit of a configuration deadlock.
I think there's probably a few things that need to be looked at. I've made these changes to get things going at my end for now. These are all in templates/web-deployment.yaml.
1) Minor typos (note concoures vs concourse)
{{- if .Values.concoures.web.awsSecretsManager.region }}
- name: AWS_REGION
value: {{ .Values.concoures.web.awsSecretsManager.region }}
{{- end }}
{{- if .Values.concoures.web.awsSecretsManager.pipelineSecretTemplate }}
- name: CONCOURSE_AWS_SECRETSMANAGER_PIPELINE_SECRET_TEMPLATE
value: {{ .Values.concoures.web.awsSecretsManager.pipelineSecretTemplate | quote }}
...
{{- if .Values.concoures.web.awsSsm.region }}
- name: AWS_REGION
value: {{ .Values.concoures.web.awsSsm.region }}
{{- end }}
2) SSM Seems to be creeping into a Secrets Manager block (not sure if this is on purpose?)
{{- if .Values.concourse.web.awsSecretsManager.enabled }}
- name: CONCOURSE_AWS_SECRETSMANAGER_ACCESS_KEY
valueFrom:
secretKeyRef:
name: {{ template "concourse.concourse.fullname" . }}
key: aws-secretsmanager-access-key
- name: CONCOURSE_AWS_SECRETSMANAGER_SECRET_KEY
valueFrom:
secretKeyRef:
name: {{ template "concourse.concourse.fullname" . }}
key: aws-secretsmanager-secret-key
{{- if .Values.secrets.awsSsmSessionToken }} <======= Is this meant to be here?
- name: CONCOURSE_AWS_SECRETSMANAGER_SESSION_TOKEN
valueFrom:
secretKeyRef:
name: {{ template "concourse.concourse.fullname" . }}
key: aws-secretsmanager-session-token
{{- end }}
3) I also experimented with removing the requirement of a key/secret/token for using Secrets Manager as opposed to just allowing an assumeRole to take its place, but that's probably a different issue to be discussed separately.
@tareks would you willing to create a pull request with your changes? I think you found the issues I am facing. I really appreciate your comment.
@Jeeppler Submitted a PR with the suggested fixes.
Feel free to pull and test. Let me know how it goes for you.
@tareks thanks for the work.
@Jeeppler Happy to help. Hope this fixed the issue you were having.
@tareks I just tried it out, but it did not work. My original problem is fixed. However, you forgot to remove the credentialManager references in web-deployment.yaml#L291 and web-deployment.yaml#L295.
{{- if .Values.credentialManager.awsSsm.pipelineSecretTemplate }}
- name: CONCOURSE_AWS_SSM_PIPELINE_SECRET_TEMPLATE
value: {{ .Values.credentialManager.awsSsm.pipelineSecretTemplate | quote }}
{{- end }}
{{- if .Values.credentialManager.awsSsm.teamSecretTemplate }}
- name: CONCOURSE_AWS_SSM_TEAM_SECRET_TEMPLATE
value: {{ .Values.credentialManager.awsSsm.teamSecretTemplate | quote }}
{{- end }}
The error message which I get while trying to install it using the Helm provider is:
* helm_release.concourse: rpc error: code = Unknown desc = render error in "concourse/templates/web-deployment.yaml": template: concourse/templates/web-deployment.yaml:289:26: executing "concourse/templates/web-deployment.yaml" at <.Values.credentialMa...>: can't evaluate field awsSsm in type interface {}
@Jeeppler I don't have much experience using SSM, so I'm not sure what these values represent. However, according to https://concourse-ci.org/creds.html#aws-ssm-pipeline-secret-template, they appear to be valid values that Concourse can use.
Did you try setting those values either in Values.yaml or on the CLI by adding something like --set credentialManager.awsSsm.pipelineSecretTemplate="/concourse/{{.Team}}/{{.Pipeline}}/{{.Secret}}" ? It looks like the current Values.yaml sets them in the concourse.web.awsSsm.pipelineSecretTemplate section, but web-deployment.yaml is referencing something older from the original 3.x chart perhaps.
In any case, do you want to open a new issue for this?
@tareks the problem still exists even if I specify the pipelineSecretTemplate and teamSecretTemplate. It is simply an syntax error from the migration process from Concourse 3.x to 4.x.
Opened a new pull request for the credentialManager issue: https://github.com/helm/charts/issues/9199
Most helpful comment
I've also experienced issues that are very likely related to this, but trying to get concourse to consume AWS Secrets Manager. It appears that the template confuses Secrets Manager and Systems Manager resulting in a bit of a configuration deadlock.
I think there's probably a few things that need to be looked at. I've made these changes to get things going at my end for now. These are all in
templates/web-deployment.yaml.1) Minor typos (note
concouresvsconcourse)2) SSM Seems to be creeping into a Secrets Manager block (not sure if this is on purpose?)
3) I also experimented with removing the requirement of a key/secret/token for using Secrets Manager as opposed to just allowing an assumeRole to take its place, but that's probably a different issue to be discussed separately.