-
Notifications
You must be signed in to change notification settings - Fork 528
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
Workflow identity federation with managed identity in Azure Kubernetes Service #2694
Comments
We don't support this type of credential out of the box, no. So any solution will require some work on your side. I will bring this up internally to evaluate options, but just for expectations, making a decision here on whether we want to support this credential out of the box or not may take time, as we usually want to have feature parity across Auth libraries.
Not from calling code, no. You can extend ServiceCredential and implement RequestAccessTokenAsync, which will only be called when the existing token is about to expire. But see my next answer first.
We are usually cautious when opening up classes for extension. But that doesn't mean we won't consider it. If I understand this correctly, STS exchange, the possibility of impersonation, etc. it's all the same. You just need to obtaing the subject token differently, right? So, you should be able to extend ExternalAccountCredential and implement GetSubjectTokenAsyncImpl? The only thing we'd need to make protected is the Initializer? Is that right? Then you can extend the initializer to add the specifics of these credentials, like the token path and tenant ID (we already have Client ID) and use those in your implementation of |
Thanks
If the |
Yes, the constructor of course, and I'm marking this as a feature request to open up ExternalAccountCredential for extensions. |
@gunndabad I have a question for you. The token from here that you send to the STS endpoint, i.e. the subject token, is it the |
@amanda-tarafa yes it’s the former. |
@gunndabad I've been talking to folks in the Identity team about this and they suggested you follow instructions to Configure workload identity federation in AKS, in particular, that you enable the OIDC issuer feature and use file sourced credentials. Things should work out of the box from there. Regardless, there's an effort across Google Auth libraries in all langauges to open up external credentials for extensibility, so we'll work on that. It just might take a little while longer, as we want to be aligned in requirements etc. Do let me know if enabling the OIDC issuer feature works for you, so I know what the urgency on implementing extensibility for externals credentials is. |
@amanda-tarafa we've set that up already (largely following the guide at https://learn.microsoft.com/en-us/azure/aks/workload-identity-deploy-cluster) but couldn't get file-sourced credentials to work. |
OK, just to report back to the Indentity team, when you say you couldn't get file-sourced credentials to work, what was the problem?
If you have a stack trace for whatever error that'd be useful as well. I'll make an attempt to try this myself and see where it gets me. |
I've tried this config: {
"type": "external_account",
"audience": "//iam.googleapis.com/projects/<our project ID>/locations/global/workloadIdentityPools/<our pool ID>/providers/<our provider ID>",
"subject_token_type": "urn:ietf:params:oauth:token-type:jwt",
"token_url": "https://sts.googleapis.com/v1/token",
"service_account_impersonation_url": "https://iamcredentials.googleapis.com/v1/projects/-/serviceAccounts/<our service account>@get-an-identity.iam.gserviceaccount.com:generateAccessToken",
"credential_source": {
"url": "https://login.microsoftonline.com/<our tenant ID>/oauth2/v2.0/token?api-version=2018-02-01&resource=api://a1039720-f1aa-4d81-9996-b305299bf0ce",
"headers": {
"Metadata": "True"
},
"format": {
"type": "json",
"subject_token_field_name": "access_token"
}
}
} With that I get:
|
At a guess, that means that Microsoft is returning HTML rather than JSON... that's normally what "I was trying to parse JSON but I got |
I suspect the MS token request is failing as there's no way to provide the contents of the |
Thanks for the info. With this, I can look into a few things:
|
Using that token directly with the |
OK, I'll get back with this info to the Identity team, just to at least clarify what they meant. It's likely then that this will fall into the "let's open external credential for extension" as we had been talking about before. I'll start planning for that as well. |
We're looking at using managed identity in AKS and identity federation to allow our apps in AKS to access resources in Google and I'm trying to work out the best way of creating a
GoogleCredential
.Using a JSON config file with a
url
credential_source
and thehttp://169.254.169.254/metadata/identity/oauth2/token
doesn't work for AKS; we have to get a token as shown here instead then pass that to the STS endpoint then create another token from that.I have this working by doing all the HTTP requests manually then passing the result to
GoogleCredential.FromAccessToken()
but this feels like a lot of work whenExternalAccountCredential
seems to already know how to do the STS parts.Questions I have:
GoogleCredential
after it's been initialized and if not what's the recommend approach for refreshing the credential?ExternalAccountCredential
ourselves that does the initial token request (it looks like everything we'd need to extend isinternal
)?The text was updated successfully, but these errors were encountered: