Conversation
enj
left a comment
enj
left a comment
There was a problem hiding this comment.
My comments are more about future customer facing docs than private preview...
|
|
||
| While the above step allows for usage of a particular user-assigned managed identity within the cluster, the cluster operator is then expected to create ClusterRole/ClusterRoleBinding identifying the namespace and the service accounts (either granularly or collectively across namespace or cluster) that are allowed to use this user-assigned managed identity for Entra authentication. | ||
|
|
||
| This OIDC issuer itself functions similarly to the AKS cluster's OIDC issuer by exposing OIDC discovery documents. Workloads running within the cluster can request a client assertion signed by the internal token provider using this issuer's dedicated signing keys. That assertion can then be exchanged for an Azure Entra token via the federated identity flow. |
There was a problem hiding this comment.
This makes it sound like the app can see the internal token, it cannot. Also the whole issuer stuff disappears with FMI...
| - IB-B mapping MI-1 to AKS-2 | ||
| - IB-C mapping MI-1 to AKS-3 | ||
|
|
||
| AKS service maintains a unique OIDC issuer for each user-assigned managed identity, whose details are generated by AKS on creation of the identity binding resource. In the above example, the issuer URL OIDC_URL-1 would be the same for M1 across the identity bindings IB-A, IB-B, and IB-C. |
There was a problem hiding this comment.
There is no such issuer with FMI though...
There was a problem hiding this comment.
let's update the doc after the next milestone?
There was a problem hiding this comment.
how about we hide "OIDC issuer" from the description at all? We can say the relations between AKS cluster and managed identity are maintained by identity binding. This can avoid confusion when trying to understand the flow.
There was a problem hiding this comment.
I don’t think we need to include implementation details here. The configuration required on MI is handled by AKS and may change in the future, but that doesn’t affect how the feature works.
|
|
||
| You can also paste this token (value of access_token field in the response) in https://jwt.ms/ to get decoded output similar to the following: | ||
|
|
||
|  |
There was a problem hiding this comment.
|  | |
|  |
| } | ||
| ``` | ||
|
|
||
| You should be able to find the FIC with name "aks-identity-binding" created under the managed identity, siimlar to this: |
There was a problem hiding this comment.
can we highlight this FIC is managed by AKS and customer should not make changes to it?
| EOF | ||
| ``` | ||
|
|
||
| 2. Identity binding private preview provides a webhook specifically for the private preview (for public preview, the managed workload identity webhook will add support for identity bindings). Install workload identity webhook using the following step: |
There was a problem hiding this comment.
we can probably skip this webhook setup for private preview onboarded clusters. They will be enabled with the private preview version of WI automatically. We can ask the customer to check for the WI version after enabling this.
| ```bash | ||
| kubectl exec -it test-shell -- bash | ||
|
|
||
| curl "https://${AZURE_KUBERNETES_SNI_NAME}" --cacert $AZURE_KUBERNETES_CA_FILE --resolve "${AZURE_KUBERNETES_SNI_NAME}:443:10.0.0.1" -d "grant_type=client_credentials" -d "client_assertion_type=urn:ietf:params:oauth:client-assertion-type:jwt-bearer" -d "scope=https://management.azure.com//.default" -d "client_assertion=$(cat $AZURE_FEDERATED_TOKEN_FILE)" -d "client_id=$AZURE_CLIENT_ID" |
There was a problem hiding this comment.
@aramase / @shashankbarsin maybe we can publish this https://github.com/bahe-msft/azure-workload-identity/tree/ib-examples/examples/identitybinding-msal-go to Azure/azure-workload-identity so customer can use the similar demo from WI?
There was a problem hiding this comment.
The code for webhook changes is in a feature branch: https://github.com/Azure/azure-workload-identity/tree/feature/custom-token-endpoint. It would be fine to have the example changes merged to that branch. I don't think we need to build the image for the demo app yet.
|
|
||
| ## Conceptual Introduction | ||
|
|
||
| An Identity binding is a mapping resource that allows customers to create mapping between one user assigned managed identity and one AKS cluster where there are workloads that require authentication to Entra using this user assigned managed identity. So let's say you have a UAMI MI-1 which needs to be used in AKS cluster AKS-1, AKS-2, AKS-3,.... you'll create the following identity binding mappings: |
There was a problem hiding this comment.
| An Identity binding is a mapping resource that allows customers to create mapping between one user assigned managed identity and one AKS cluster where there are workloads that require authentication to Entra using this user assigned managed identity. So let's say you have a UAMI MI-1 which needs to be used in AKS cluster AKS-1, AKS-2, AKS-3,.... you'll create the following identity binding mappings: | |
| An Identity binding is a mapping resource that allows customers to create mapping between one user-assigned managed identity (UAMI) and one AKS cluster where there are workloads that require authentication to Entra using this user assigned managed identity. So let's say you have a UAMI MI-1 which needs to be used in AKS cluster AKS-1, AKS-2, AKS-3,.... you'll create the following identity binding mappings: |
| - IB-B mapping MI-1 to AKS-2 | ||
| - IB-C mapping MI-1 to AKS-3 | ||
|
|
||
| AKS service maintains a unique OIDC issuer for each user-assigned managed identity, whose details are generated by AKS on creation of the identity binding resource. In the above example, the issuer URL OIDC_URL-1 would be the same for M1 across the identity bindings IB-A, IB-B, and IB-C. |
There was a problem hiding this comment.
I don’t think we need to include implementation details here. The configuration required on MI is handled by AKS and may change in the future, but that doesn’t affect how the feature works.
|
|
||
| Before identity bindings, workload identity feature required egress to be allowed for `login.microsoftonline.com` so that workloads could send requests to eSTS to exchange service account tokens for Entra access tokens. | ||
|
|
||
| With the identity binding feature, there's no need for `login.microsoftonline.com` as token exchange requests are routed via a cluster-specific identity binding specific proxy deploy on AKS service. |
There was a problem hiding this comment.
| With the identity binding feature, there's no need for `login.microsoftonline.com` as token exchange requests are routed via a cluster-specific identity binding specific proxy deploy on AKS service. | |
| With the identity binding feature, there's no need for `login.microsoftonline.com` as token exchange requests are routed via a cluster-specific identity binding specific proxy deployed on AKS service. |
|
|
||
| # Create resource group, AKS cluster, and identity bindings | ||
| az group create --name $RESOURCE_GROUP -l $LOCATION | ||
| az aks create -g $RESOURCE_GROUP -n $CLUSTER -l $LOCATION --no-ssh-key |
There was a problem hiding this comment.
| az aks create -g $RESOURCE_GROUP -n $CLUSTER -l $LOCATION --no-ssh-key | |
| az aks create -g $RESOURCE_GROUP -n $CLUSTER -l $LOCATION --no-ssh-key --enable-workload-identity |
The webhook needs to be enabled.
| } | ||
| ``` | ||
|
|
||
| You should be able to find the FIC with name "aks-identity-binding" created under the managed identity, siimlar to this: |
There was a problem hiding this comment.
| You should be able to find the FIC with name "aks-identity-binding" created under the managed identity, siimlar to this: | |
| You should be able to find the FIC with name "aks-identity-binding" created under the managed identity, similar to this: |
| name: test | ||
| subjects: | ||
| - kind: ServiceAccount | ||
| name: default |
There was a problem hiding this comment.
Might be better to use non-default name/namespace in the example
| EOF | ||
| ``` | ||
|
|
||
| 2. Identity binding private preview provides a webhook specifically for the private preview (for public preview, the managed workload identity webhook will add support for identity bindings). Install workload identity webhook using the following step: |
There was a problem hiding this comment.
This step is not required, it should be handled with --enable-workload-identity
| ```bash | ||
| kubectl exec -it test-shell -- bash | ||
|
|
||
| curl "https://${AZURE_KUBERNETES_SNI_NAME}" --cacert $AZURE_KUBERNETES_CA_FILE --resolve "${AZURE_KUBERNETES_SNI_NAME}:443:10.0.0.1" -d "grant_type=client_credentials" -d "client_assertion_type=urn:ietf:params:oauth:client-assertion-type:jwt-bearer" -d "scope=https://management.azure.com//.default" -d "client_assertion=$(cat $AZURE_FEDERATED_TOKEN_FILE)" -d "client_id=$AZURE_CLIENT_ID" |
There was a problem hiding this comment.
The code for webhook changes is in a feature branch: https://github.com/Azure/azure-workload-identity/tree/feature/custom-token-endpoint. It would be fine to have the example changes merged to that branch. I don't think we need to build the image for the demo app yet.
5 participants
No description provided.