Describe the bug
When providing aws.assumeRoleArn using a valid Role, which the EKS has permission to assume, I get the following error:
time="2019-07-19T17:08:19Z" level=fatal msg="SharedConfigAssumeRoleError: failed to load assume role for arn:aws:iam::<account-id>:role/<role-name>, source profile has no shared credentials"
Version of Helm and Kubernetes:
helm: v2.14.1
EKS: 1.12
Which chart:
stable/external-dns
What happened:
Cannot get external-dns to access hosted zone in another AWS Account
What you expected to happen:
external-dns to assume the role provided, and update the hosted zone values
How to reproduce it (as minimally and precisely as possible):
Create a role on destination AWS account with proper policy to update route53 hosted zone resource record set. Then on origin AWS account, where the EKS cluster is running, create a policy that allows to assume the role created in destination AWS account, and attach it to EKS worker role.
Anything else we need to know:
If we don't add the aws.assumeRoleArn value, it tries to look for the hosted zone in origin account, and fails, because its not there.
@agustin-caylent just an FYI I found this after searching a bit
https://github.com/helm/charts/issues/10886#issuecomment-466469997
I still think this Issue is necessary but I can confirm it works as expected
Hi @the-real-cphillips , thanks for the comment! I saw that, but if I am not mistaken it was a workaround for aws.roleArn (which as I understand, is now replaced with aws.assumeRoleArn).
The use of this annotation requires you having setup kube2iam, right? And we currently don't have or plan to have it.
Does aws.assumeRoleArn requires the use of aws.credentials.accessKey and aws.credentials.secretKey instead of the default profile? The role currently set in the workers node, is allowed to assume the needed role.
Hi @the-real-cphillips , thanks for the comment! I saw that, but if I am not mistaken it was a workaround for
aws.roleArn(which as I understand, is now replaced withaws.assumeRoleArn).The use of this annotation requires you having setup
kube2iam, right? And we currently don't have or plan to have it.
I believe you are correct in that it is/was a workaround, we are using aws-iam-authenticator.
I had incorrectly assumed you were too 馃槃
Hi,
Could you confirm if it works using AWS credentials?
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Any further update will cause the issue/pull request to no longer be considered stale. Thank you for your contributions.
This issue is being automatically closed due to inactivity.
this is still an issue with Chart 2.11.0, even worse, it totally broke after 2.10.2
For now I forked the chart and use following diff to ensure external-dns 5.17.0 uses the EC2 instance profile credentials to assume the role
diff --git external-dns/templates/deployment.yaml ../charts/external-dns/templates/deployment.yaml
index d565e91..564c443 100644
--- external-dns/templates/deployment.yaml
+++ ../charts/external-dns/templates/deployment.yaml
@@ -292,7 +292,7 @@ spec:
{{- end }}
volumeMounts:
# AWS mountPath(s)
- {{- if and (eq .Values.provider "aws") (or .Values.aws.assumeRoleArn (and .Values.aws.credentials.secretKey .Values.aws.credentials.accessKey)) }}
+ {{- if and (eq .Values.provider "aws") (and .Values.aws.credentials.secretKey .Values.aws.credentials.accessKey) }}
- name: aws-credentials
mountPath: {{ .Values.aws.credentials.mountPath }}
readOnly: true
@@ -328,7 +328,7 @@ spec:
{{- end }}
volumes:
# AWS volume(s)
- {{- if and (eq .Values.provider "aws") (or .Values.aws.assumeRoleArn (and .Values.aws.credentials.secretKey .Values.aws.credentials.accessKey)) }}
+ {{- if and (eq .Values.provider "aws") (and .Values.aws.credentials.secretKey .Values.aws.credentials.accessKey) }}
- name: aws-credentials
secret:
secretName: {{ template "external-dns.fullname" . }}
we simply do not mount the aws config file for assumeRoleArn - note that I pass in aws.region through flags as well ...
Most helpful comment
Hi @the-real-cphillips , thanks for the comment! I saw that, but if I am not mistaken it was a workaround for
aws.roleArn(which as I understand, is now replaced withaws.assumeRoleArn).The use of this annotation requires you having setup
kube2iam, right? And we currently don't have or plan to have it.