Skip to content

✨ feat: Support setting EKS authentication mode #5578

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

Open
wants to merge 13 commits into
base: main
Choose a base branch
from

Conversation

joshfrench
Copy link

What type of PR is this?
/kind feature

What this PR does / why we need it:
Support setting EKS AuthenticationMode.

Which issue(s) this PR fixes (optional, in fixes #<issue number>(, fixes #<issue_number>, ...) format, will close the issue(s) when PR gets merged):
Partially addresses #4854

Special notes for your reviewer:
This PR just finishes the work started in #5108 by rebasing, removing the API changes to v1beta1, and fixing the fuzzy tests. There were two seemingly unrelated changes in the original PR that I've removed:

  • Add CGFLAGS to build command (I'm dropping this as unrelated)
  • One documentation fix that I'll resubmit in its own PR

Checklist:

  • squashed commits
  • includes documentation
  • includes emoji in title
  • adds unit tests
  • adds or updates e2e tests

Release note:

Added support for setting EKS AuthenticationMode (required for migrating to EKS Access Entries)

@k8s-ci-robot k8s-ci-robot added release-note Denotes a PR that will be considered when it comes time to generate release notes. kind/feature Categorizes issue or PR as related to a new feature. do-not-merge/contains-merge-commits cncf-cla: yes Indicates the PR's author has signed the CNCF CLA. needs-priority labels Jul 2, 2025
@k8s-ci-robot k8s-ci-robot requested review from AndiDog and faiq July 2, 2025 13:24
@k8s-ci-robot
Copy link
Contributor

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by:
Once this PR has been reviewed and has the lgtm label, please assign fabriziopandini for approval. For more information see the Code Review Process.

The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@k8s-ci-robot
Copy link
Contributor

Welcome @joshfrench!

It looks like this is your first PR to kubernetes-sigs/cluster-api-provider-aws 🎉. Please refer to our pull request process documentation to help your PR have a smooth ride to approval.

You will be prompted by a bot to use commands during the review process. Do not be afraid to follow the prompts! It is okay to experiment. Here is the bot commands documentation.

You can also check if kubernetes-sigs/cluster-api-provider-aws has its own contribution guidelines.

You may want to refer to our testing guide if you run into trouble with your tests not passing.

If you are having difficulty getting your pull request seen, please follow the recommended escalation practices. Also, for tips and tricks in the contribution process you may want to read the Kubernetes contributor cheat sheet. We want to make sure your contribution gets all the attention it needs!

Thank you, and welcome to Kubernetes. 😃

@k8s-ci-robot k8s-ci-robot added needs-ok-to-test Indicates a PR that requires an org member to verify it is safe to test. size/L Denotes a PR that changes 100-499 lines, ignoring generated files. labels Jul 2, 2025
@k8s-ci-robot
Copy link
Contributor

Hi @joshfrench. Thanks for your PR.

I'm waiting for a kubernetes-sigs member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

Copy link
Contributor

@punkwalker punkwalker left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@joshfrench
Thank you for working on this.This will unblock my work for EKS Hybrid Node Cluster #5245.
Just few suggestion/question. Otherwise LGTM.

Comment on lines +257 to +263
type AccessConfig struct {
// AuthenticationMode specifies the desired authentication mode for the cluster
// Defaults to CONFIG_MAP
// +kubebuilder:default=CONFIG_MAP
// +kubebuilder:validation:Enum=CONFIG_MAP;API;API_AND_CONFIG_MAP
AuthenticationMode EKSAuthenticationMode `json:"authenticationMode,omitempty"`
}

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As we are creating a AccessConfig, I suggest we add bootstrapClusterCreatorAdminPermissions as well,
If we do not plan to support this field, do we really need the AccessConfig struct?

WDYT @nrb @damdo ?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

bootstrapClusterCreationAdminPermissions can only be set at cluster creation; the UpdateAccessConfigRequest API doesn't allow changing this. I don't have a strong opinion on adding the new field vs. removing the struct, but we'll need to account for that.

(For additional context, #5583 adds AccessEntry definitions to this struct but now I'm second-guessing where those should live.)

Copy link
Contributor

@punkwalker punkwalker Aug 8, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Here is what I think,
We have spec.iamAuthenticatorConfig in ManagedControlPlane. This is used for adding entries in aws-auth configmap.

Similary, we should have separate spec.AccessEntries for role/user mapping and spec.authenticationMode to specify access mode. Because, the default value for mode is CONFIG_MAP which would be required for creating mapping from [spec.iamAuthenticatorConfig].

@joshfrench Let me know what you think?

Also, bootstrapClusterCreatorAdminPermissions can be part of AuthenticationMode struct and have default value true as in CONFIG_MAP mode, regardless of the value, clusterCreator will have admin permissions.

@AndiDog Please share your thoughts.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@punkwalker Agreed that spec.AccessEntries should be a separate field (still planning to handle that in a separate PR.)

To clarify, you are suggesting we add bootstrapClusterCreatorAdminPermissions to AccessConfig and default it to true?

type AccessConfig struct {
    // +kubebuilder:default=CONFIG_MAP
    // +kubebuilder:validation:Enum=CONFIG_MAP;API;API_AND_CONFIG_MAP
    AuthenticationMode EKSAuthenticationMode `json:"authenticationMode,omitempty"`

    // +kubebuilder:default=true
    BootstrapClusterCreatorAdminPermissions bool `json:"bootstrapClusterCreatorAdminPermissions"`
}

That feels right to me, since it matches the shape of the EKS API.

My question was what we should do if the user changes bootstrapClusterCreatorAdminPermissions on an existing cluster. The UpdateAccessConfig API doesn't allow it, because it makes no sense once the cluster has been boostrapped already. The only valid use of UpdateAccessConfig is to change the authentication mode.

So if a user changes bootstrapClusterCreationAdminPermissions on an existing cluster we could:

  1. Ignore bootstrapClusterCreatorAdminPermissions entirely and only submit the request if it changes the authentication mode
  2. Submit the request if it changes the authentication mode and log a warning if bootstrapClusterCreatorAdminPermissions also changes
  3. Fail validation and return an error if bootstrapClusterCreationAdminPermissions changes, regardless of whether the authentication mode also changes

1 feels bad, 2 is low friction, 3 is the most explicit. Thoughts?

Comment on lines 565 to 566
expectedAuthenticationMode := string(s.scope.ControlPlane.Spec.AccessConfig.AuthenticationMode)
currentAuthenticationMode := string(accessConfig.AuthenticationMode)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we need this type conversion? Should be enough to compare the values as we already have a Type for AuthenticationMode.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

one of these is from the AWS ekstypes pkg, the other from our own v1beta2

@joshfrench
Copy link
Author

@punkwalker Thanks for the feedback, I'll be able to circle back to this next week.

@@ -249,6 +253,15 @@ type EndpointAccess struct {
Private *bool `json:"private,omitempty"`
}

// AccessConfig represents the access configuration information for the cluster
type AccessConfig struct {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
type AccessConfig struct {
type Access struct {

(and JSON field name access)

All YAML is "config", so I'd remove that word unless it's part of "official" AWS terminology, for instance.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The upstream types and API docs both use AccessConfig.

@k8s-ci-robot k8s-ci-robot added the needs-rebase Indicates a PR cannot be merged because it has merge conflicts with HEAD. label Aug 4, 2025
@k8s-ci-robot k8s-ci-robot removed do-not-merge/contains-merge-commits needs-rebase Indicates a PR cannot be merged because it has merge conflicts with HEAD. labels Aug 8, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
cncf-cla: yes Indicates the PR's author has signed the CNCF CLA. kind/feature Categorizes issue or PR as related to a new feature. needs-ok-to-test Indicates a PR that requires an org member to verify it is safe to test. needs-priority release-note Denotes a PR that will be considered when it comes time to generate release notes. size/L Denotes a PR that changes 100-499 lines, ignoring generated files.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants