-
Notifications
You must be signed in to change notification settings - Fork 3.9k
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
fix(eks): fargateCluster compatibility with AuthenticationMode.API #31267
Conversation
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 pull request linter has failed. See the aws-cdk-automation comment below for failure reasons. If you believe this pull request should receive an exemption, please comment and provide a justification.
A comment requesting an exemption should contain the text Exemption Request
. Additionally, if clarification is needed add Clarification Request
to a comment.
✅ Updated pull request passes all PRLinter validations. Dismissing previous PRLinter review.
…ode (#31258) ### Issue # (if applicable) This PR improve the compatibility for `albController` with `authenticationMode.API` related to #30888 We will address Fargate compatibility in #31267 ### Reason for this change - When `authenticationMode.API` is specified, no aws-auth configMap should be created - albController should not depend on `cluster.awsAuth` because that would create aws-auth configmap, which is not required in `API` mode. ### Description of changes ### Description of how you validated changes **unit tests** - validate the behavior in all conditions of the `authenticationMode` **integ test** - add a new integ test with API mode to ensure successful deployment ## debugger ```js { "version": "0.2.0", "configurations": [ { "type": "node", "request": "launch", "name": "Jest", "program": "${workspaceFolder}/node_modules/jest/bin/jest.js", "cwd": "${workspaceFolder}/packages/aws-cdk-lib", "args": [ "--verbose", "-i", "--no-cache", "test/alb-controller.test.ts", ], "console": "integratedTerminal", "internalConsoleOptions": "neverOpen", "skipFiles": [ "<node_internals>/**" ], "outFiles": [ "${workspaceFolder}/**/*.(m|c|)js", "!**/node_modules/**" ], } ] } ``` ### Checklist - [x] My code adheres to the [CONTRIBUTING GUIDE](https://github.com/aws/aws-cdk/blob/main/CONTRIBUTING.md) and [DESIGN GUIDELINES](https://github.com/aws/aws-cdk/blob/main/docs/DESIGN_GUIDELINES.md) ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
const supportConfigMap = props.cluster.authenticationMode !== AuthenticationMode.API ? true : false; | ||
if (supportConfigMap) { |
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.
Seems to me like something that was unconditional is now conditional, and PR body doesn't tell me anything about what the problem was or why this is the fix.
That's leaving me to wonder: what are the backwards compatibility implications of 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.
Thank you. Just fixed.
'system:node-proxier', | ||
], | ||
}); | ||
const supportConfigMap = props.cluster.authenticationMode !== AuthenticationMode.API ? true : false; |
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.
Concluding support for something by exclusion works in a closed world, but I'm not sure the world is actually closed. If a 4th authentication method is added in the future, will this condition have to be updated? Isn't is safer to inclusively check for one of the CONFIG_MAP
options?
@@ -1142,6 +1142,37 @@ You can disable granting the cluster admin permissions to the cluster creator ro | |||
|
|||
> **Note** - Switching `bootstrapClusterCreatorAdminPermissions` on an existing cluster would cause cluster replacement and should be avoided in production. | |||
|
|||
When a `FargateCluster` is created with `AuthenticationMode.API`, by default the cluster creator role would be added into the AccessEntry with `AmazonEKSClusterAdminPolicy` unless `bootstrapClusterCreatorAdminPermissions` is disabled. |
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'm not sure what this line is trying to tell me, exactly.
Isn't the behavior of adding the creator user, except when you set a flag, the same as the behavior describer 2 sentences above? What does the qualification about the AuthenticationMode add? Why is this a separate line and not integrated into the previous description?
Please refrain from using non-present tenses like "would". It's not the Amazon docs writing style, and is unnecessarily indirect. We can just say "will".
I can spot it just above this change as well. I know you didn't change it in this PR, but improving the overall writing style and condensing/rewriting bad or redundant docs will be a help overall. Better than endlessly adding standalone lines just to have covered the new feature, that will make the docs unreadable over time.
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.
Thank you! Yes it is redundant after reviewing the description. I just removed it from the README.
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 pull request linter has failed. See the aws-cdk-automation comment below for failure reasons. If you believe this pull request should receive an exemption, please comment and provide a justification.
A comment requesting an exemption should contain the text Exemption Request
. Additionally, if clarification is needed add Clarification Request
to a comment.
56f1a72
to
ddf65bb
Compare
✅ Updated pull request passes all PRLinter validations. Dismissing previous PRLinter review.
10c58a4
to
75cb15a
Compare
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 pull request linter has failed. See the aws-cdk-automation comment below for failure reasons. If you believe this pull request should receive an exemption, please comment and provide a justification.
A comment requesting an exemption should contain the text Exemption Request
. Additionally, if clarification is needed add Clarification Request
to a comment.
✅ Updated pull request passes all PRLinter validations. Dismissing previous PRLinter review.
Hi @rix0rrr , all addressed. Thank you. |
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.
LGTM, I think Pahud has addressed Rico's feedback. Approving on behalf for Rico. In summary, this shouldn't be a breaking change because the original code won't work when authenticationMode
is API because in this mode, config map is not supported and this statement would just fail.
➡️ PR build request submitted to A maintainer must now check the pipeline and add the |
@mergify update |
❌ Mergify doesn't have permission to updateFor security reasons, Mergify can't update this pull request. Try updating locally. |
Dismissing stale review as I believe Rico's comments are addressed.
Thank you for contributing! Your pull request will be updated from main and then merged automatically (do not update manually, and be sure to allow changes to be pushed to your fork). |
AWS CodeBuild CI Report
Powered by github-codebuild-logs, available on the AWS Serverless Application Repository |
Thank you for contributing! Your pull request will be updated from main and then merged automatically (do not update manually, and be sure to allow changes to be pushed to your fork). |
Comments on closed issues and PRs are hard for our team to see. |
Issue # (if applicable)
This PR ensures the eks fargateCluster compatibility with
AuthenticationMode.API
Closes #30888
Reason for this change
The FargateCluster assumes the authentication mode is always config map and create the podExectionRole mapping using
props.cluster.awsAuth.addRoleMapping()
. This won't work when authenticationMode isAPI
because in this mode, config map is not supported and this statement would just fail.We need to add an conditional check, only when the cluster supports configmap will it run the addRoleMapping() statement. At this moment, the following authenticationMode would support configmap:
undefined
CONFIG_MAP
API_AND_CONFIG_MAP
Description of changes
Description of how you validated changes
Checklist
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license