oauth2-proxy: Azure provider does not work when "resource" is used - fails to retrieve email
on AKS 1.20.2, I’m using oauth2-proxy as a ext-authz
extension for istio. I want to protect Kiali
. Kiali has multiple authorization strategies, one of them being the header
strategy, which would work perfectly with oauth2-proxy
. My goal is to forward the kubernetes user token, retrieved using oauth2-proxy from Azure Kubernetes AAD, to kiali, which would then use it to query the kubernetes resources.
I basically want to get an access token to kubernetes through oauth2-proxy, through Azure Kubernetes AD, forward it to Kiali, then kiali would use that to query the Kubernetes API on behalf of the user.
On AKS, there’s an integration with Active Directory for RBAC permissions, which is enabled in our clusters. The Kubernetes API is configured with an OpenID provider, being the public Azure Kubernetes AD. So users have to do az aks get-credentials
, which guides them through an oidc flow, then configures their kube.config
.
I registered an Azure App, which has the Azure Graph user.read
permission, as well as the user.read
permission on the Azure Kubernetes AD
service. The id
of this public service is 6dae42f8-4368-4678-94ff-3960e28e3630
I can successfully login trough the istio ext-authz
set up on our ingress gateway, then I’m redirected to kiali. But this does not forward the actual kubernetes token to kiali yet.
If I set the oauth2-proxy
resource
parameter to 6dae42f8-4368-4678-94ff-3960e28e3630
(the Azure Kubernetes AD
), then there’s an error. The error is that oauth2-proxy cannot retrieve the user email
from the graph api (InvalidAudience)
Since the id_token
and access_token
returned by azure do not include the email, oauth2-proxy
tries to retrieve the email from the graph
api. This works when the resource
parameter is not set, but if fails with an InvalidAudience
error if the resource
parameter is set.
I tried setting the oauth2-proxy
scope
arguments to openid email profile
or openid,email,profile
, but it seems that it does not include the email in the response.
Back to the root of the error, I guess that the reason behind this is that the access token used to query the graph
api is the token for the “protected resource” (in this case Azure Kubernetes AD) which does not have permission to query the Graph API.
Expected Behavior
- Should not fail to retrieve the email when using a protected resource
Current Behavior
- The query fails to retrieve the email from the id_token, access_token and graph api
Possible Solution
- Perhaps the Graph API request could be made with a token that was retrieved “not” on the protected resource
- Find another way of including the email in the id_token or access_token from Azure
Your Environment
AKS 1.20.2
- Version used: latest
oauth2-proxy [2021/03/31 10:47:07] [azure.go:165] unable to get email claim from id_token: <nil>
oauth2-proxy [2021/03/31 10:47:07] [azure.go:173] unable to get email claim from access token: <nil>
oauth2-proxy [2021/03/31 10:47:07] [oauthproxy.go:809] Error creating session during OAuth2 callback: unable to get email address: unexpected status "401": {
oauth2-proxy "error": {
oauth2-proxy "code": "InvalidAuthenticationToken",
oauth2-proxy "message": "Access token validation failure. Invalid audience.",
oauth2-proxy "innerError": {
oauth2-proxy "date": "2021-03-31T10:47:07",
oauth2-proxy "request-id": "XXXXX",
oauth2-proxy "client-request-id": "XXXXXX"
oauth2-proxy }
oauth2-proxy }
oauth2-proxy }
token received with the “resource” param:
{
"aud": "UUID",
"iss": "https://sts.windows.net/TENANT_ID/",
"iat": 2983129083,
"nbf": 2983129083,
"exp": 2983129083,
"aio": "REDACTED",
"appid": "REDACTED",
"appidacr": "1",
"idp": "https://sts.windows.net/TENANT_ID/",
"oid": "OBJECT_ID",
"rh": "REDACTED",
"sub": "REDACTED",
"tid": "REDACTED",
"uti": "REDACTED",
"ver": "1.0"
}
About this issue
- Original URL
- State: open
- Created 3 years ago
- Reactions: 12
- Comments: 40 (34 by maintainers)
still an issue
still an issue
still an issue
The problem is getting bigger #1505 (also #1231 is involved)
@JoelSpeed It is absolutely worth a try. Whereas hoping that Azure fixes the behavior is quite naive.
In general, where a provider is OIDC compatible, we are looking to deprecate the existing providers and either encourage people to use the OIDC provider directly or convert the existing providers to be extensions of the existing OIDC providers.
So I think documenting using Azure on the OIDC provider would be great
I had the same issue and I solved it using
--oidc-email-claim=sub
.However, it fails to refresh the cookie with the following error:
well, after removing some token customizations I had made while trying to make this work, I changed
--scope=user.read
back into--scope=openid
and it eventually worked… Not sure why my id_tokens weren’t signed before, and now they are signed. Go figure…