I'm running an eks cluster, installed k8s dashboard etc. All works fine, I can login in the UI in
http://localhost:8001/api/v1/namespaces/kubernetes-dashboard/services/https:kubernetes-dashboard:/proxy/#/login
Is there a way for me to pass the token via the url so I won't need a human to do this?
Thanks!
Based on official documentation it is impossible to put your authentication token in URL.
As of release 1.7 Dashboard supports user authentication based on:
Authorization: Bearer <token> header passed in every request to Dashboard. Supported from release 1.6. Has the highest priority. If present, login view will not be shown.
Bearer Token that can be used on Dashboard login view.
Username/password that can be used on Dashboard login view.
Kubeconfig file that can be used on Dashboard login view.
As you can see, only the first option bypasses the Dashboard login view. So, what is Bearer Authentication?
Bearer authentication (also called token authentication) is an HTTP authentication scheme that involves security tokens called bearer tokens. The name “Bearer authentication” can be understood as “give access to the bearer of this token.” The bearer token is a cryptic string, usually generated by the server in response to a login request. The client must send this token in the Authorization header when making requests to protected resources:
You can find more information about Baerer Authentication here.
The question now is how you can include the authentication header in your request. There are many ways to achieve this:
curl command - example:
curl -H "Authorization: Bearer <TOKEN_VALUE>" <https://address-your-dashboard>
Postman application - here is good answer to set up authorization header with screenshots.
reverse proxy - you can be achieve this i.e. by configuring reverse proxy in front of Dashboard. Proxy will be responsible for authentication with identity provider and will pass generated token in request header to Dashboard. Note that Kubernetes API server needs to be configured properly to accept these tokens. You can read more about it here. You should know, that this method is potentially insecure due to Man In The Middle Attack when you are using http.
You can also read very good answers to the question how to sign in kubernetes dashboard.
Related
I am trying to upload file from local to GCP bucket through cloud storage Rest API (https://storage.googleapis.com/upload/storage/v1/b) using Postman.
I am using Bearer Token for authorization and running $(gcloud auth print-access-token) command on GCP Shell to generate that token every time.
I need to know, how to auto generate that token from Postman while sending request ?
Is there any way to execute $(gcloud auth print-access-token) every time as a Pre-request Script within Postman ?
Thanks
I'm not very good with postman, but I think you can run pre-request to get token and reuse it in the subsequent request.
If so, you can get inspiration from the gcloud auth print-access-token command by adding the --log-http param to visualize the request performed by the CLI and to reproduce them in Postman.
EDIT 1
If you perform the request, you can see that a post is performed to this URL https://oauth2.googleapis.com/token
To reproduce the call, you can try with a curl
curl -X POST -d "grant_type=refresh_token&client_id=32555940559.apps.googleusercontent.com&client_secret=ZmssLNjJy2998hD4CTg2ejr2&refresh_token=<REFRESH_TOKEN>&scope=openid+https%3A%2F%2Fwww.googleapis.com%2Fauth%2Fuserinfo.email+https%3A%2F%2Fwww.googleapis.com%2Fauth%2Fcloud-platform+https%3A%2F%2Fwww.googleapis.com%2Fauth%2Fappengine.admin+https%3A%2F%2Fwww.googleapis.com%2Fauth%2Fcompute+https%3A%2F%2Fwww.googleapis.com%2Fauth%2Faccounts.reauth" https://oauth2.googleapis.com/token
In this call, you need your REFRESH_TOKEN, that you can get here
cat ~/.config/gcloud/legacy_credentials/<YOUR EMAIL>/adc.json
Google Cloud Storage requires authentication as other Google APIs and one of the authentication way is providing bearer token. These bearer tokens are short lived and require regeneration.
So there are 3 ways to generate bearer tokens so you can interact with Google Storage API or other Google APIs using Postman:
Using oauth2l CLI ( Manual Regeneration of new bearer token and update of Authorization header with the new token)
This oauth2l CLI utility allows you to generate bearer tokens which can be pasted into the Authorization header in postman. You can use
Configuration of Postman with OAuth 2 and User Credentials ( Tokens can be managed via the Postman UI and expired ones cleaned up at the click of a button)
Postman can be configured to trigger the OAuth 2 flow and use a generated bearer token in all of the requests. But please make sure that all users have the correct permissions in the Google Cloud Platform project.
You will need to create OAuth 2 credentials in Google Cloud Console:
Go to APIS and Services
Then go to Credentials tab
Click on Create Credentials
Select OAuth Client ID
Fill the fields to create OAuth Client ID ( also add an Authorized redirect URI however this doesn’t need to resolve to anywhere).
The Client ID and Client Secret need to be saved in your machine.
Use Postman’s environment variable functionality to use different credentials per environment/project. In Postman create a new environment for your credentials using the cog icon at the top right.
Configure the variables accordingly: AUTH_CALLBACK_URL , AUTH_URL, AUTH_CLIENT_ID, AUTH_CLIENT_SECRET, AUTH_ACCESS_TOKEN_URL
This variable should be identical to that defined in the OAuth 2 Client ID creation menu and should be one of the following : AUTH_SCOPE
Once defined, these variables can be used in your Authorization tab in Postman. This can be configured at the collection level, the folder level or even the individual request level.
To Regenerate the Token, you can go to Authorization Tab and click on GET NEW ACCESS TOKEN
Configuration of Postman to use a pre-request script and service credentials (The pre-request script automatically regenerates the bearer token when it expires)
For this please check this Tutorial to follow the steps provided there.
When a request with the bearer token hits a microservice, does microservice talk to keycloak to validate the token for each request?
Is traffic "Step 5" configurable via keycloak adapter?
No, that would make too many requests. In initialization phase microservice loads public key and signing algorithm from Keycloak’s well known config page. On each request microservice checks the signature of the bearer token.
Access token lifespan should not be too long and that is how you force your frontend to periodically go to Keycloak and refresh the bearer.
If you run your microservice, every time you send a request to an api after adding the token in the logs you will see "Loaded URLs from http://localhost:8080/auth/realms/{realm-name}/.well-known/openid-configuration". Upon clicking this link you will see that there are a set of URLs present here, endpoints for token generation, userinfo etc.,there are endpoints for getting the certs and signing keys as well via which the signing key of the token is verified.
(This will only happen if keycloak properties are defined in application.properties/application.yml)
Step 5 will happen on using Keycloak adapter (Choice of adapter given in keycloak documentation)
I'm using keycloak as authorization server. The users send own username/password to MyWebApp and MyWebApp with grant_type: password get the token and then response token to the user. Now I want to my users be able to get their information, change their password and everything related to themselves RESTFUL. When I send a rest request to /{realm}/users/{id} to get user information, The keycloak get 403 error response. How can I get user information without admin access from keyclaok?
Note: I've seen this question, But I want to give the user edit profile too.
I think you are using Oauth with Grant type=password. If the token you mentioned is generate by Keycloak. You can request user information to Keycloak using /userinfo endpoint.
This is example of endpoint:
"http://localhost:8080/auth/realms/demo/protocol/openid-connect/userinfo"
This is how to send the parameters:
https://connect2id.com/products/server/docs/api/userinfo
GET /userinfo HTTP/1.1
Host: c2id.com
Authorization: Bearer Gp7b5hiURKpWzEXgMJP38EnYimgxlBC1PpS2zGXUqe
As far as i know in new versions of Keycloak, Account application (~/auth/realms/{realm}/account) will be implemented as REST backend so your users will be able to work with their profile data in RESTful way (check out keycloak blog).
If you can't wait too long for such feature, you could implement your own REST backend for user profile operations. It mean that you have to implement REST endpoint Service Provider, and integrate to that API your custom set of Keycloak Roles (Your also may to implement endpoint without checks for any roles, so only bearer authentication required). Check Keycloak development docs, also you could use Keycloak sources, especially org.keycloak.services.resources.admin package as implementation example.
PS. For viewing user info, consider using User Info OIDC endpoint (See Hlex answer). It also could be customized via OIDC mappers (Clients -> {client Id} -> Mappers tab)
I am following this doc for reference.
I am able to get information for secure gateway, which is already created. But when I am trying to create a new secure gateway from the REST API, it is asking for authentication. I have tried to provide the authentication information two ways:
I have provided the oauth authorization header obtained from the cf oauth-token, but it gives me an unauthorized error.
I have given basic authentication (username and password of the Bluemix account) information, but it gives me an unauthorized error.
Note: I am using postman for this operation
Postman details:
url: https://sgmanager.au-syd.bluemix.net/v1/sgconfig?org_id=girishxxxxxxx#gmail.com&space_id=Equxxxxx
It is also saying "Invalid org_id", but the org_id is valid.
To create a gateway via the SG API, your request will need the query parameters ord_id and space_id (the guids, not the friendly names). The authorization header will be Basic <your_base64_encoded_username:password> or Bearer <bluemix_token>. For example:
curl "https://sgmanager.au-syd.bluemix.net/v1/sgconfig?org_id=myOrgGuid&space_id=mySpaceGuid" -H "Authorization: Basic dXNlcm5hbWU6cGFzc3dvcmQ=" -d '{"desc":"My Gateway"}'
Currently in Kubernetes you can make use of the webhook authorization to build a custom authorization endpoint using certificates. In reading the doucmentation it looks like if I wanted to use a bearer token there is no way to use the webhook, I have to use point Kube to a csv file with the --token-auth-file argument.
The downside with that is that requires a restart of the api server to pick up the changes. Is there a dynamic way to use bearer tokens instead?