-
Notifications
You must be signed in to change notification settings - Fork 137
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
add fsgroup for securityContext #342
Conversation
config/manager/deployment.yaml
Outdated
securityContext: | ||
fsGroup: 1337 |
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.
securityContext: | |
fsGroup: 1337 | |
securityContext: | |
# Required for AWS IAM Role bindings | |
# https://docs.aws.amazon.com/eks/latest/userguide/iam-roles-for-service-accounts-technical-overview.html | |
fsGroup: 1337 |
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.
Does either Notification Controller or Helm Controller actually use AWS IAM role bindings though?
I didn't add this comment because I was unsure of the reason why this might be needed here.
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.
(I accepted the change so you can get this merged and it will conform to the rest, regardless I'd like to understand the answer.)
We had someone on Slack who was actively experiencing this issue but I was not able to get them to confirm this fixes 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.
Maybe the answer was, they bound some annotations to AWS IAM roles to Flux service accounts and didn't include it in their report. I would guess the presence of the role binding is what causes the fsGroup setting to be needed, (not the actual utilization of the AWS IAM role) but I would just be guessing at that.
(The issue reporter was on EKS, at least that much I can say for sure. But we had others confirm that EKS at-large is not affected, so it must be something particular about this one EKS cluster.)
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.
What is interesting is that the latest EKS docs mention the following:
Providing this security context is not required for 1.19 or later clusters.
— https://docs.aws.amazon.com/eks/latest/userguide/iam-roles-for-service-accounts-technical-overview.html#Pod-configuration
I think we should create an issue to get to the bottom of this, as it looks like it can be deprecated in the future.
457494f
to
e0051d4
Compare
@kingdonb can you squash please? |
Signed-off-by: Kingdon Barrett <kingdon@weave.works>
e0051d4
to
206c2fe
Compare
So there is still fluxcd/flux2#2537 which we can ping for follow-up. |
Ref: fluxcd/flux2#2537
In fluxcd/source-controller#284 (comment) it seems that leaving
fsGroup
unset can result in this error.