I have a kubernetes cluster and i have my application deployed in the pods. There is a endpoint URL of my application which i used to send POST requests from Postman. I need to provide some level of authentication to the my URL. I read the service account authentication using the JWT token.
How can i achieve the same feature in postman ??
I tried creating a new service account and took the secret and the associated JWT token as the Bearer token in postman. But it is not giving any kind of authentication.
https://medium.com/better-programming/k8s-tips-using-a-serviceaccount-801c433d0023
Cant directly answer your question, but from what comes to my mind is that: Istio supports Token-based end-user authentication with JSON Web Tokens.
You should understand I havent tried to do that, but this looks for me very promising: Istio End-User Authentication for Kubernetes using JSON Web Tokens (JWT) and Auth0
And to test JWT-based authentication and authorization workflow thay exactly use Postman, as you prefer.
Related
I am trying to use Keycloak behind an API gateway (Apache APISIX).
I use minikube to run Keycloak and my API gateway.
The gateway is working right and Keycloak too :
With Keycloak, I can use the different end-point (use the discovery end-point (http://127.0.0.1:7070/auth/realms/myrealm/.well-known/uma2-configuration), ask an access token and verify it).
With APISIX, and a simple route, I can join a backend microservice on my minikube.
(typically : http://127.0.0.1:80/greeting is served by the gateway which routes the request to the right backend microservice)
The problem occurs when I try to use the two tools together. I have used the Keycloak integration, in order to force the user to use a valid token when he is using a route served by the gateway.
In this case, when I use a valid bearer token (I get it and verify it with the end-point of keycloak), and I try to request the backend via the api gateway with the verified bearer token, I obtain systematically an "Invalid bearer token" exception.
{"error":"invalid_grant","error_description":"Invalid bearer token"}
I think the settings of the integration is well set because I am sure that te gateway call Keycloak to verify the token.
Here are the keycloak I have used to get and verify the token :
Get token : http://127.0.0.1:7070/auth/realms/myrealm/protocol/openid-connect/token
Verify : http://127.0.0.1:7070/auth/realms/myrealm/protocol/openid-connect/token/introspect
I have seen some posts about problem when Keycloak is behind a reverse proxy, but I don't find a clear solution to my case.
Thanks for any help you can bring to me.
Regards
CG
I think there are those ways you can do it.
First, I think you can check the log of Apache APISIX.
Second, you can check the log of Keycloak.
Third, you can use tcpdump or wireshark to capture the request that Apache APISIX sends to keycloak.And diff the request that sends by APISIX and curl.
Looking forward to your reply.
Prerequisites
I have two Cloud Run services a frontend and a backend. The frontend is written in Vue.js/Nuxt.js and is using a Node backend therefore. The backend is written in Kotlin with Spring Boot.
Problem
To have an authenticated internal communication between the frontend and the backend I need to use a token thttps://cloud.google.com/run/docs/authenticating/service-to-service#javahat is fetched from the google metaserver. This is documented here: https://cloud.google.com/run/docs/authenticating/service-to-service#java
I did set it all up and it works.
For my second layer of security I integrated the Auth0 authentication provider both in my frontend and my backend. In my frontend a user can log in. The frontend is calling the backend API. Since only authorized users should be able to call the backend I integrated Spring Security to secure the backend API endpoints.
Now the backend verifies if the token of the caller's request are valid before allowing it to pass on to the API logic.
However this theory does not work. And that simply is because I delegate the API calls through the Node backend proxy. The proxy logic however is already applying a token to the request to the backend; it is the google metaserver token. So let me illustrate that:
Client (Browser) -> API Request with Auth0 Token -> Frontend Backend Proxy -> Overriding Auth0 Token with Google Metaserver Token -> Calling Backend API
Since the backend is receiving the metaserver token instead of the Auth0 Token it can never successfully authorize the API call.
Question
Due the fact that I was not able to find any articles about this problem I wonder if it's simply because I am doing it basically wrong.
What do I need to do to have a valid Cloud Run Service to Service communication (guaranteed by the metaserver token) but at the same time have a secured backend API with Auth0 authorization?
I see two workarounds to make this happen:
Authorize the API call in the Node backend proxy logic
Make the backend service public available thus the metaserver token is unnecessary
I don't like any of the above - especially the latter one. I would really like to have it working with my current setup but I have no idea how. There is no such thing like multiple authorization token, right?
Ok I figured out a third way to have a de-facto internal service to service communication.
To omit the meta-server token authentication but still restrict access from the internet I did the following for my backend cloud run service:
This makes the service available from the internet however the ingress is preventing any outsider from accessing the service. The service is available without IAM but only for internal traffic.
So my frontend is calling the backend API now via the Node backend proxy. Even though the frontend node-backend and the backend service are both somewhat "in the cloud" they do not share the same "internal network". In fact the frontend node-backend requests would be redirected via egress to the internet and call the backend service just like any other internet-user would do.
To make it work "like it is coming from internal" you have to do something similar like VPN but it's called VPC (Virtual Private Cloud). And luckily that is very simple. Just create a VPC Connector in GCP.
BUT be aware to create a so called Serverless VPC Access (Connector). Explained here: https://cloud.google.com/vpc/docs/serverless-vpc-access
After the Serverless VPC Access has been created you can select it in your Cloud Run Service "Connection" settings. For the backend service it can be simply selected. For the frontend service however it is important to select the second option:
At least that is important in my case since I am calling the backend service by it's assigned service URL instead of a private IP.
After all that is done my JWT token from the frontend is successfully delivered to the backend API without being overwritten by a MetaServer token.
I'm building a microservice based REST API and a native SPA Web Frontend for an application.
The API should be protected using OAuth2.0 to allow for other clients in the future. It should use the Authorization Code Flow ideally with Proof Key for Code Exchange (PKCE)
As I understand it I need to run my own OAuth Auth Server that's managing the API Clients and generating access tokens, etc.
Also I need my own Authentication/IAM service with it's own fronted for user login and client authorization granting. This service is the place the users login credentials are ultimately checked against a backend. That last part should be flexible and the backend might be an LDAP server in some private cloud deployment.
These components (Auth Server and IAM servicve) are outside of the OAuth scope but appear, correct me if I'm wrong, to be required if I'm running my own API for my own users.
However creating these services myself appears to be more work than I appreciate besides the obvious security risks involved.
I read about auth0 and okta but I'm not sure if they are suited for my use case with the application potentially deployed in private cloud.
I also thought about running Hydra (OAuth Server) and Kratos (IAM) by ory but I'm not sure if this is adding too many dependencys to my project.
Isn't there an easy way to secure an API with OAuth that deals with the Auth Server and the IAM that's good for small projects?!
I want to access the kubernetes dashboard and the API using an already existing openid connect session (apache reverse proxy with mod_auth_openidc + WSO2 identity server). Unfortunately, kubernetes requires an id_token as a bearer token (signed JWT), which is quite hard to obtain by just having the session cookie from mod_auth_openidc module.
My problem is the following: When I call the the OIDCInfoHook with the id_token configured (the reverse proxy callback_url like http://service.domain?json=info), I just get the unsigned id_token token, which is useless for kubernetes authentication. Calling the info hook with the refresh token configured I can retrieve successfully the refresh token. With this token the identity server (WSO2) returns the id_token, a new access token and the next refresh token. Unfortunately, the mod_auth_openidc still has the old access_token and I need to map to the new the id_token to the old and new access token. Although it works after a fresh login, optaining the id_token doesn't work anymore after the session timeout (3600 s). In this state, I have to delete manually the session cookie in order to get a new login prompt.
I have two questions:
Is there any other possibility to use oidc authentication with kubernetes that does not rely on the id_token, i.e. using one the openid connect flows as described in the spec? According to the openid connect spec, the id_token should not be send around and this method seems not to be one of the openid connect flows, I guess.
Is there any other best practice way to integrate kubernetes into an existing openid connect based single sign on environment?
The common SSO solution for this kind of problems is to use Kubernetes OAuth2-Proxy, https://github.com/pusher/oauth2_proxy. You could either run the proxy in an ingress or in a side car container. If you have istio, you could also integrate Istio with your openid conenect provider.
I saw the word "endpoint" many times in OAuth documents.. However, I still don't know what does this word really mean.. Does anyone have ideas about this?
The OAuth 2.0 Authorization Framework
The authorization process utilizes two authorization server endpoints
(HTTP resources):
Authorization endpoint - used by the client to obtain
authorization from the resource owner via user-agent redirection.
Token endpoint - used by the client to exchange an
authorization
grant for an access token, typically with client authentication.
Its basically the HTTP web address of the authentication server. It could probably be server addresses depending upon how its worked. The first is for requesting access of the user the second could be for granting access to the application. this probably depends upon how the Authentication server is set up.
OAuth endpoints are the URLs you use to make OAuth authentication requests to Server. You need to use the correct OAuth endpoint when issuing authentication requests in your application. The primary OAuth endpoints depend upon the system you are trying to access.
Example Google has two end points:
Request access of user:
https://accounts.google.com/o/oauth2
Exchange tokens
https://accounts.google.com/o/oauth2/token