OK so I can see this exact thing has been discussed here before, and there are lots of convo’s in the google groups about this very issue.
So mine is actually working now, the groups are returned in the claim and I can assign policies using external groups and alias’s but I dont understand why this is working.
I spent days trying to troubleshoot this, trying weird and wonderful combinations of the auth/oidc/role/rolename config but always the same error
Groups not found in claim.
Every piece of hashicorp documentation, every KB I have found and almost every article of poor souls struggling on stackoverflow has the same piece of config for the role creation, namely this line
groups_claim="roles"
Except for this one glorious, magnificent pain saving article
Half way down there is a comment from rgevaert, and in there config they actually use
groups_claim="roles" \
instead of
groups_claim="groups" \
I have altered my config to be the same and boom its now working for me which is amazing, but why?
Why does it work with roles as the keyword and not groups?
Why is this not documented anywhere? (apologies if it is and ive missed it)
How did this magnificent human being know to switch that to be roles instead of groups?
Any clarification here would be massively appreciated.
Additionally when troubleshooting I could see users where able to locate at the JWT returned in logs. How do I also view this when troubleshooting. I have deployed vault to k8s on rancher and there are no logs in the containers within /vault/log or /var/log. I can see some logs by doing a kubectl logs pod-name but nothing shows for the token. Admittedly I may have missed some config in the helm chart to make it actually save log files but I dont think I have.
Old topic but totally my issue. I get failed to fetch groups: "groups" claim not found in token but not with group_claims="roles".
The poster said he could not see oidc verbose logging in Kubernetes logs. I couldn’t either. And without this, troubleshooting is really difficult.
All I needed to do was lower Vault’s log level. (more info) I have a helm chart also, so that meant adding this to the chart
server:
logLevel: "debug"
and then restarting Vault.
Ah… “debug” level now shows in kubernetes logs. (I use k9s tool to easily see it, but tailing kubectl log works also.)
I am using Okta and I can see “groups” in the claim from Okta’s token tester, and also see in the event log that Vault is requesting the proper scopes. (Reports - System Log - GrantedScopes deep in the event data). However Vault’s log shows me it does not get the same result as Okta’s token tester, and it is in fact missing “groups”.
Well I go back to Okta application OIDC configuration and notice a typo on the group filter. Corrected - and now - UNDERSTOOD success!
If there is still a doubt as to why groups_claim=“roles” works and not groups_claims=“groups”. In Azure App registration - Customize token types properties, if you leave the [EMIT groups as roles claims] selected it will show up as “role” claims in the token which works for groups_claim=“roles”. If you deselect the option, then it emits as “group” claims in the token, which then works for groups_claim=“groups”.