Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
State of this PR :
It is paused
Starting with kubectl 1.26, cloud-dependent methods of authenticating (used by aks and gke) where deprecated. We did the transition for gke, and though that it was needed for aks, but, as it turns out, everything still seems to be working fine (tested with plugin version 1.2.0, using kubectl 1.26 creating a k8s cluster at version 1.26.0)
So, for now, this developpement is stalled.
How auth currently works
We create a
kube_config
file, with at least the following section:in practice, this means we authenticate using a (probably derived only once) given token. The associated identity is
clusterAdmin
, and we create (or maybe it already exists ?) a clusterrolebinding on the cluster with full rights:What this PR changes
The
kube_config
is changed to look like this :Meaning that we are going to use
kubelogin
to fetch a token. Note that there is several ways to identify oneself to get this token (dentity-resource-id, client-id, etc...), but the gist of it is that we are going to use an IAM identity, most probably the one set-up by DCS. I will be refered to adss-id-jcasoli
.(as a aside
6dae42f8-4368-4678-94ff-3960e28e3630
is a hard-coded azure constant, it just means ~"aks service")Note that, for kubelogin to work with Azure identites, we must setup our cluster to use
Azure AD authentication
. This is automatically set-up at the cluster creation by the plugin.The token we get is an Oauth token, granted to
dss-id-jcasoli
. <= very importantThis token will be handled by aks control plane, but there is two possibility here:
Kubernetes RBAC
option :dss-id-jcasoli
. This is theAzure RBAC
option :Both options have issues, which we don't know how to handle automatically for now. (the following are from memory, some of it may be slightly incorrect)
Kubernetes RBAC
, the k8s control plane will receive a token that is valid for userdss-id-jcasoli
. However, it does not know this user, and we hence have to add it / add a corresponding clusterbindingrole. This could be done using aks cli, but, at that moment, the only iam identity we have isdss-id-jcasoli
, which lacks enough rights to create theclusterbindingrole
Azure RBAC
, we encounter mostly the same issue, but with the additional indirection of Azure AD.Indeed, DCS' doc says that
dss-id-jcasoli
should be aContributor
of the k8s Cluster (actually of the whole ressource group), which seems to be equivalent to giving hime theAzure Kubernetes Service Contributor Role
rights, while we probably would needAzure Kubernetes Service RBAC Admin