Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Adding rad install changes for AWS IRSA support #7741
Adding rad install changes for AWS IRSA support #7741
Changes from 7 commits
4b65354
7da1a87
0781da1
d49e676
a1e8018
ed398bb
fcd6718
13f3352
2bc7e54
aff2f10
cfb5e80
9f55960
7dfbbbf
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
the parameter name should be global.aws.irsa.enabled , based on ryan's comment..
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
updated it!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@nithyatsu did we say during design discussion that IRSA can be enabled on non EKS clusters as well? Would this mount path still be applicable on other clusters?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hi Karishma, IRSA is not specific to eks clusters. But the first iteration of the feature is based on eks.
We would have to make the token path configurable in order to support it on other clusters too. Would it be OK to log a ticket to cover this?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@nithyatsu yeah that sounds good as long as it is intentional and being tracked
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
created #7774 for tracking this.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this actually something we'd have to change for another cluster?
From what I understand, the AWS SDKS will use the value of AWS_WEB_IDENTITY_TOKEN_FILE to load the token. There's nothing special about this file path (or any other file path) as long as the environment variable points to the token on disk.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@rynowak In code, we added the token file location as a const:
radius/pkg/recipes/terraform/config/providers/aws.go
Line 56 in 007f7e6
The mount path should work, but it felt odd to reference eks in path for a cluster that was not on eks. Or is it OK since IRSA is a AWS feature? Also, instead of const, should I have looked to set the env variable for the pods?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
IMO we should do the following:
AWS_WEB_IDENTITY_TOKEN_FILE
to/var/run/secrets/eks.amazonaws.com/serviceaccount/token
in the helm chart when IRSA is enabled. This is also done by the webhook here.AWS_WEB_IDENTITY_TOKEN_FILE
. linkThen it doesn't matter what the path is, because it's not hardcoded.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
updated the ticket #7774 to implement this comment.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@nithyatsu @vishwahiremat could you share details on how did we decide on this number?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hi Karishma, the typical approach for IRSA was to use the pod identity webhook. (
ref. https://github.com/radius-project/design-notes/blob/3b3f66e7b6d340ef7beebcc4212fcd7129bf8b06/cli/2024-06-04-aws-irsa-support.md#alternatives-considered , https://github.com/aws/amazon-eks-pod-identity-webhook#amazon-eks-pod-identity-webhook)
The reason we did not choose the webhook was since it wasnt compatible with multi-tenancy and needed service restarts to register credential. But, we did the exact same thing the webhook does. These are the configurations the webhook sets (https://github.dev/aws/amazon-eks-pod-identity-webhook#amazon-eks-pod-identity-webhook) and mentions it as a default value.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this should be similar to