-
Notifications
You must be signed in to change notification settings - Fork 623
✨ 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
base: main
Are you sure you want to change the base?
Conversation
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: 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 |
Welcome @joshfrench! |
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 Once the patch is verified, the new status will be reflected by the 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. |
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.
@joshfrench
Thank you for working on this.This will unblock my work for EKS Hybrid Node Cluster #5245.
Just few suggestion/question. Otherwise LGTM.
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"` | ||
} | ||
|
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.
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?
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.
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.)
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.
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.
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.
@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:
- Ignore
bootstrapClusterCreatorAdminPermissions
entirely and only submit the request if it changes the authentication mode - Submit the request if it changes the authentication mode and log a warning if
bootstrapClusterCreatorAdminPermissions
also changes - 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?
pkg/cloud/services/eks/cluster.go
Outdated
expectedAuthenticationMode := string(s.scope.ControlPlane.Spec.AccessConfig.AuthenticationMode) | ||
currentAuthenticationMode := string(accessConfig.AuthenticationMode) |
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.
Do we need this type conversion? Should be enough to compare the values as we already have a Type for AuthenticationMode.
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.
one of these is from the AWS ekstypes
pkg, the other from our own v1beta2
@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 { |
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.
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.
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 upstream types and API docs both use AccessConfig
.
This reverts commit 62e4137.
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:
Checklist:
Release note: