Skip to content
This repository has been archived by the owner on Jul 15, 2021. It is now read-only.

Deprecate use of emailClaim. #87

Merged
merged 2 commits into from
Nov 29, 2018

Conversation

paulczar
Copy link
Contributor

In order to support multiple clusters in the future we need each
username in the kubeconfig to be unique. Therefore rather than using
the user's email from their oidc auth, we should construct it from
usernameClaim and clusterName.

Of course we should also deprecate it nicely, so if emailClaim is set
it will override that default and still use their OIDC email address and
print a warning message in the logs.

Signed-off-by: Paul Czarkowski username.taken@gmail.com

In order to support multiple clusters in the future we need each
username in the kubeconfig to be unique.  Therefore rather than using
the user's email from their oidc auth, we should construct it from
usernameClaim and clusterName.

Of course we should also deprecate it nicely, so if emailClaim is set
it will override that default and still use their OIDC email address and
print a warning message in the logs.

Signed-off-by: Paul Czarkowski <username.taken@gmail.com>
@paulczar
Copy link
Contributor Author

Resolves #86

@@ -57,14 +57,14 @@ $ sudo mv ./kubectl /usr/local/bin/kubectl
<code class="language-bash">
echo "{{ .ClusterCA }}" \ > ca-{{ .ClusterName }}.pem
kubectl config set-cluster {{ .ClusterName }} --server={{ .APIServerURL }} --certificate-authority=ca-{{ .ClusterName }}.pem --embed-certs
kubectl config set-credentials {{ .Username }}@{{ .ClusterName }} \
kubectl config set-credentials {{ .Email }} \
Copy link
Contributor

Choose a reason for hiding this comment

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

@paulczar in the issue we discussed making this user@cluster?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

yes, which it is ... just its doing it in the logic that was fetching emailClaim rather than in the template. see here. Instead of completely ignoring emailClaim it will use it if provided in a config (with a deprecation warning ) and if its not set it sets the existing email field to be username@cluster.

Thus both the new and the old work, and the deprecation can be remove later at a suitable time with a major version cut.

Copy link
Contributor

Choose a reason for hiding this comment

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

Ahh I see. My only nit is that it's confusing if you just look at the template file. Maybe a different variable name would make sense just to make it clear?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yeah, I thought that as well, but I thought for the sake of not messing with the various data structures it would be best to leave it as is.

Copy link
Contributor

Choose a reason for hiding this comment

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

Ok thats fine, we can rework for v2. 😁

log.Println("email Handler")
return
email := strings.Join([]string{username, cfg.ClusterName}, "@")
if cfg.EmailClaim != "" {
Copy link
Contributor

Choose a reason for hiding this comment

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

Could we add some tests to cover this new logic?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

tests added!

Signed-off-by: Paul Czarkowski <username.taken@gmail.com>
Copy link
Contributor

@stevesloka stevesloka left a comment

Choose a reason for hiding this comment

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

lgtm!

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