Token validation works if queried passing by Nodeport and fails if queried passing by Cluster IP

Hello.

I have this problem.

I have deployed keycloak on kubernetes.

I succeed in login the user accessing from Nodeport.

But when a pod inside the cluster wants to validate the token from inside the cluster, we receive 401 Unauthorized error.

If the same pod pass by the nodeport to validate the token, then it’s validated.

I don’t think is a good practice to get out the cluster and re-enter when we are already inside the cluster.

When I need to login the user, is ok to pass from the nodeport.

But when I need to validate the token for an action in the application, I need to stay inside the cluster.

My question is how to keep the nodeport for the login and how to allow the token validation from within the cluster.

Thank you

@gmesml Sorry to bother you… I am stucked!!! I saw yout reply to this post Rest API inside cluster local access and It might be the same issue but I didn’t get how to fix it…

Simply if I try to validate the token from inside the cluster the token is not validated and If I pass from outside the cluster it is validated!! The same token!!

1 Like

Greetings fullstackunicorn,

our context was like: The host was unreachable by any other container inside the cluster.
Since it is unknown how do you build and run your containers or how you’ve automated that process.

Don’t know if you are using docker-compose or you just build them once and not deal at all.
Also don’t know if you are using reverse-proxy traefik or something else.

In our context we just gave a domain to keycloak and added a host parameter to each other container where we needed to access it internally (not externally/over public).

After completing the settlment above this is the API request we perform to keycloak to validate tokens:

Get Request:
https://keycloak-domain/auth/realms/your-realm-id/protocol/openid-connect/userinfo

Header params:
Authorization: Bearer token
Accept: application/json

Response example:
{
“sub”: “4b510fba-d5c5-4554-8cc8-563dd6c5fb33”,
“email_verified”: false,
“name”: “John Doe”,
“preferred_username”: “johndoe”,
“given_name”: “John”,
“family_name”: “Doe”,
“email”: “john@doe.com
}

The official documentation: Keycloak Admin REST API

And you should be aware, based on which part of API you want to consume there are lots of different variations. Some of them like above, require just the realm as parameter to identify what you want to access.

Other requests may require realm and client-id. And if you need to consume Admin REST API, you need to learn to make use of admin-cli client, that would require to perform an authentication request, obtaining a server-side token (storing it on cache/session) and assign it to your future request header params and proceed further.

Often official documentation can be confusing if you’re coming with a background from non-enterprise industry. There is a different mindset on enterprise, when using keycloak api you must break down every relationship as roles/groups and treat them as entire resources.

Additional postman collection example:

Personally I wasn’t involved on keycloak setup so don’t know if you need to perform extra steps to activate open-id protocol, but from what I know we’re making use of official docker image following these section of instructions Keycloak - Guide - Keycloak on Docker

This is what should a Realm management look like:

Essentially https://keycloak-domain/auth/admin/master/console/#/realms/Test-Realm
the end of url Test-Realm is the realm id you should be using on your requests as param.
Afterwards when you dive in to clients and other features you’ll be building the proper mindset to understand and relate what goes where and how stuff relate with each other.

Thank you very much @gmesml !!
Ok I think I got the general idea, now I try to implement it and I will publish a detailed report of what was the problem and how I solved!