Currently, I am connecting to a corporate vault service where I am using a vault token and passing it through below header in my spring cloud config service where properties of all microservices are kept.
curl -X "GET" "http://localhost:8080/my-client-microservice/dev" -H "X-Config-Token: s.myvaulttoken"
where http://localhost:8080 is my spring cloud config service and s.myvaulttoken is my vault token. This is working absolutely fine.
I want to know the validity of this token. What I have read the documentation that token can be of two type: service or batch. I want to know whether this token can be used infinitely (as root tokens validity is infinite).
Since the client microservices require the vault token, I want to figure out the way to know the validity of a token. Can you guys help me to tell more about this?
I followed this link: https://learn.hashicorp.com/vault/getting-started/authentication
Every non-root token has a time-to-live (TTL) associated with it.
For example:
with a root token, the ttl is 0
vault token lookup -format json | jq .data.ttl
0
with a regular user, the ttl is non-zero
VAULT_TOKEN=$(vault token create -policy default -field token) vault token
lookup -format json | jq .data.ttl
2764799
This check is possible through the API as well.
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.
I want to create base authentication in kubernetes. every document say that I should create CSV or file then enter the username and password in it. but I do not want to use file I want to some database or kubernetes handle it.
what can I do for base authentication?
You can based your authentication on tokens if you don't want to use static pasword file.
First option:
Service Account Tokens
A service account is an automatically enabled authenticator that uses signed bearer tokens to verify requests.
The plugin uses two flags(which are optional):
Service accounts are usually created automatically by the API server and associated with pods running in the cluster through the ServiceAccount Admission Controller. Bearer tokens are mounted into pods at well-known locations, and allow in-cluster processes to talk to the API server. Accounts may be explicitly associated with pods using the serviceAccountName field of a PodSpec.
Service account bearer tokens are perfectly valid to use outside the cluster and can be used to create identities for long standing jobs that wish to talk to the Kubernetes API. To manually create a service account, simply use the kubectl create serviceaccount (NAME) command. This creates a service account in the current namespace and an associated secret.
The created secret holds the public CA of the API server and a signed JSON Web Token (JWT).
The signed JWT can be used as a bearer token to authenticate as the given service account. See above for how the token is included in a request. Normally these secrets are mounted into pods for in-cluster access to the API server, but can be used from outside the cluster as well.
There is some drawbacks because service account tokens are stored in secrets, any user with read access to those secrets can authenticate as the service account. Be careful when granting permissions to service accounts and read capabilities for secrets.
Second:
Install OpenID Connect (full documentation you can find here: oidc).
OpenID Connect (OIDC) is a superset of OAuth2 supported by some service providers, notably Azure Active Directory, Salesforce, and Google. The protocol’s main addition on top of OAuth2 is a field returned with the access token called an ID Token. This token is a JSON Web Token (JWT) with well known fields, such as a user’s email, signed by the server.
To identify the user, the authenticator uses the id_token (not the access_token) from the OAuth2 token response as a bearer token.
Since all of the data needed to validate who you are is in the id_token, Kubernetes doesn’t need to “phone home” to the identity provider. In a model where every request is stateless this provides a very scalable solution for authentication.
Kubernetes has no “web interface” to trigger the authentication process. There is no browser or interface to collect credentials which is why you need to authenticate to your identity provider first.
There’s no easy way to authenticate to the Kubernetes dashboard without using the kubectl proxy command or a reverse proxy that injects the id_token.
More information you can find here: kubernetes-authentication.
I'm trying to get login/pass authentication working on Vault.
When I try the method given in the API documentation here: https://www.vaultproject.io/api/auth/userpass/index.html#login
I get this error:
$ curl --request POST --data #payload.json https://<myurl>:8200/v1/auth/userpass/login/<mylogin> -k
{"errors":["missing client token"]}
And I can't find information on this error. It makes me wonder what happens, because I want to authenticate with login/pass to get the token, so that's just normal to not have it.
Here is the content of the payload.json:
{
"password": "foo"
}
Is there any way to login with username/password? This is the only fallback method I have when the user does not know its token.
Thanks!
OK, so I figured it out by trials.
So the userpass AUTH was indeed disabled. I have to use LDAP auth. With the Vault-UI that is installed, I managed to find the URL to authenticate. If was the following : https://******:8200/v1/auth/<ldap>/login/<user>
And that way it's working.
Unfortunately, it does not help in the end. The idea was to synchronize Vault data locally, but the Vault API is really not built for that kind of access. It requires a LOT of requests, and end up being very slow for a few secrets synchronized.
Make sure you are logging in under the correct namespace. You will get this error if your authentication method is enabled under something other than the default namespace that your CLI tool is using.
You can specify the namespace with the -ns=my/namespace/ parameter or the VAULT_NAMESPACE environment variable.
For example, if your namespace is "desserts/icecream"
vault login -ns=desserts/icecream/ -method=userpass username=ian
# OR
export VAULT_NAMESPACE=desserts/icecream/
vault login -method=userpass username=ian
In my case, i was not setting the vault token to the right environment variable.
you have to set the value to VAULT_TOKEN so that it uses it in subsequent request my env variable was Vault_Token and due to this it was always saying missing client token.
By default, Vault checks for this environment variable to find the token.
vault kv get --field "ACCESS_KEY_ID" secret/my-secret
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?
I am currently playing around with the Kong API Gateway and I would like to use it to validate the authentication of users at the gateway and restrict access to services if the user is not logged in properly.
I have an authentication service which issues JWTs whenever a user logs in.
I would now like to share the JWT secret with Kong and use it for validation of the issued JWTs to secure services which need proper authentication.
I had a look at this plugin: https://getkong.org/plugins/jwt/
But it seems that this plugin works a bit different than what I would like to achieve. Why do I have to create consumers? I would like to have only one user database at my authentication service to avoid the need of synchronisation. It seems that the approach of this plugin is designed for giving 3rd party stakeholders access to my API.
Any hint would be highly appreciated.
The answer given by Riley is sort of correct in implementation but that is not the intended use of a consumer in the Kong.
A consumer in kong is the application that is is using the API. So, unless you have multiple vendors using your app/web service, I suggest you create a single consumer.
You can create multiple key and secret pair(JWT credentials) for that consumer. Create a JWT for a user by using the users Key and secret. Store this Key and secret in your current database along with your userID and other details. Create your JWT using these and return the JWT to the user.
Anything else you want to append as a claim can be added to the JWT while you are creating it. You can create a check for these claims in Kong. So, when you get a call to any of your APIs along with these JWT Kong will check the validity of the JWT(along with all the claims) and only then allow the access to the API.
It seems to me that the design of the JWT plugin for Kong doesn't want to share a JWT secret with you - it wants to own the JWTs entirely. You will indeed have to create a consumer per user, and let Kong manage that.
I asked a few questions to confirm on the Google Group - see https://groups.google.com/forum/?fromgroups#!topic/konglayer/XHnVEGoxZqo
Two highlights:
Can you just confirm that it should be OK to make one consumer and one credential per user?
Not only that's okay, but that's the recommended way :)
and
Will Kong be happy to have two million consumers of a single api? What about 200 million?
Technically that shouldn't be an issue, I would recommend setting up a POC where you can experiment with a higher number of users, in order to optimize the connection between Kong and the datastore and make sure we tune everything properly.
You can actually pass the secret to the JWT plugin when you create it:
$ curl -X POST http://kong:8001/consumers/${consumer_id}/jwt \
-H "Content-Type: application/x-www-form-urlencoded" \
--data "secret=mysecret&consumer_id=${consumer_id}"