Skip to content
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

feat: Starting with 1.30, do not use the cluster OIDC issuer URL by default in the identity provider config #3055

Conversation

bryantbiggs
Copy link
Member

Description

  • Starting with 1.30, do not use the cluster OIDC issuer URL by default in the identity provider config
  • The example referenced in the v19 upgrade doc has been corrected to better reflect the intended behavior enforced by this change

Motivation and Context

Conflicting issuers between JWT authenticators and service account config are now detected and fail on API server startup. Previously such a config would run but would be inconsistently effective depending on the credential.

The prior default value of the cluster (control plane) OIDC issuer URL was incorrect and should not be used in this context. Users should provider their issuer's URL for their identity provider (i.e. - Cognito, Okta, Auth0, etc.). Therefore, this change is aligning with the upstream Kubernetes project to ensure users provide the correct issuer URL when associating additional identity providers to their cluster

Breaking Changes

  • Yes'ish - it requires users to potentially make changes if they are currently, and incorrectly, utilizing the cluster's OIDC issuer url. But, if they don't, the API server will reject this and fail

How Has This Been Tested?

  • I have updated at least one of the examples/* to demonstrate and validate my change(s)

  • I have tested and validated these changes using one or more of the provided examples/* projects

    1. Created a cluster on 1.29 with the following config:
       ...
       cluster_identity_providers = {
         example = {
           client_id  = "1234567890abc"
         }
       }
       ...
    1. Once the cluster has provisioned, change the Kubernetes version to 1.30 and execute:
     terraform plan
    1. From the plan, the following error is now shown to users:
      image
    2. To resolve, users will need to explicitly provide the *correct issuer URL (if you incorrectly re-provide the cluster's OIDC issuer URL, the API server will fail). For example, continuing the example above, updating the configuration to something like this now plans successfully (these are contrived values, but they demonstrate the intended behavior of the change):
       ...
       cluster_identity_providers = {
         example = {
           client_id  = "1234567890abc"
           issuer_url = "https://myissuer.com"
         }
       }
       ...
  • I have executed pre-commit run -a on my pull request

@bryantbiggs bryantbiggs changed the title fix: Starting with 1.30, do not use the cluster OIDC issuer URL by default in the identity provider config feat: Starting with 1.30, do not use the cluster OIDC issuer URL by default in the identity provider config May 31, 2024
@bryantbiggs bryantbiggs merged commit 00f076a into terraform-aws-modules:master May 31, 2024
18 checks passed
@bryantbiggs bryantbiggs deleted the fix/identity-provider-config-default branch May 31, 2024 17:01
antonbabenko pushed a commit that referenced this pull request May 31, 2024
## [20.13.0](v20.12.0...v20.13.0) (2024-05-31)

### Features

* Starting with `1.30`, do not use the cluster OIDC issuer URL by default in the identity provider config ([#3055](#3055)) ([00f076a](00f076a))
@antonbabenko
Copy link
Member

This PR is included in version 20.13.0 🎉

Copy link

github-actions bot commented Jul 1, 2024

I'm going to lock this pull request because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues. If you have found a problem that seems related to this change, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Jul 1, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants