Using http api to init vault does not accept base64 gpg key but CLI does - hashicorp-vault

I am using the http api for initialising vault and encrypting the seal keys and root token, but I am getting
{"errors":["error decoding given PGP key: illegal base64 data at input byte 21"]}
But when I use the CLI it works.
How do I get it working for the http api??
This done using ubuntu 18.04 and gpg (GnuPG) v2.2.4, base64 v8.28, latest vault
Here is the command for command line interface that works, and returns the seal keys and root token encrypted:
./vault operator init -key-shares=2 -key-threshold=2 -address="http://127.0.0.1:8200" -format="json" -root-token-pgp-key="mo.asc" -pgp-keys="mo.asc,mo.asc"
The above was run in the same directory as the vault instance was started using
./vault server -config=vaultconfig.hcl
The vaultconfig.hcl contains
storage "inmem" {}
listener "tcp" {
address = "127.0.0.1:8200"
tls_disable = 1
}
mo.asc was obtained using the following:
gpg --gen-key
gpg --export <generated key> | base64 > mo.asc
The command for using the http api that does not work
curl --request PUT --data #payload.json http://127.0.0.1:8200/v1/sys/init
payload.json is
{
"secret_shares": 2,
"secret_threshold": 2,
"pgp_keys": [
"mo.asc",
"mo.asc"
],
"root_token_pgp_key": "mo.asc"
}
This returns:
{"errors":["error decoding given PGP key: illegal base64 data at input byte 21"]}
But if I change the payload.json to
{
"secret_shares": 2,
"secret_threshold": 2
}
it works returning
{
"keys": [
"227e3b43a76b54008249b39285ae1063db0e2bff94bad0f349f4b7fa89195fb7d7",
"2ab2f5ec67191c26735116f5a1cc9b3bab406eff7b57d9632359a0797f2cf5fd3e"
],
"keys_base64": [
"In47Q6drVACCSbOSha4QY9sOK/+UutDzSfS3+okZX7fX",
"KrL17GcZHCZzURb1ocybO6tAbv97V9ljI1mgeX8s9f0+"
],
"root_token": "s.s2GZsomY2tGJfQzHGFjqlYNu"
}
It seems the CLI command accepts that my gpg is base64 encrypted, but the http api does not accept it is encrypted. Although it seems the CLI is using the http api underneath. The http api is working, but only when I add the asc file to the payload.json it does not work.
Am I missing something?
How do I think this so I get encrypted root token and keys when initialising vault via http api?
Thanks

Related

Unable to Send Custom headers for zap-api-scan.py, headers are declared in options.prop

Unable to send Custom headers for zap-api-scan.py, headers are declared in options.prop
I want to use zap to scan a rest API endpoint which requires Authorization & X-api-key header.
To specify the header, I have configured these in options.prop file.
But when I run
docker run -v $(pwd):/zap/wrk/:rw -t owasp/zap2docker-weekly zap-api-scan.py -t <API URL> -f openapi -z "-configfile /zap/wrk/options.prop"
I feel prop file is not getting picked. I get 401 error, as my Authorization token is not picked up.
Below is how my options.prop file looks
replacer.full_list(0).description=Authorization
replacer.full_list(0).enabled=true replacer.full_list(0).matchtype=REQ_HEADER
replacer.full_list(0).matchstr=Authorization
replacer.full_list(0).regex=false
replacer.full_list(0).replacement=<Token>
replacer.full_list(1).description=x-api-key
replacer.full_list(1).enabled=true
replacer.full_list(1).matchtype=REQ_HEADER
replacer.full_list(1).matchstr=x-api-key
replacer.full_list(1).regex=false
replacer.full_list(1).replacement=<Value>

Keycloak does not have all the Keys available in the storage

I have created a realm and added new keystore(RS384) in the Providers section
When I tried authenticate using postman. I am getting below error in Keycloak console
PublicKey wasn't found in the storage. Requested kid: 'Y3RDLAudovJPEU3Z9BMJL3OyuzqsgAj4424CpxnJqkI' . Available kids: '[]'
Kid is available in the Keys section for the Realm. I am not sure what is causing that. Any help on this is so much appreciated
Edit
Client Authentication
Added JWKS keys from certs endpoint
In Postman made call to token endpoint with client_assertion which has signed JWT and got response back "Invalid client: Unable to load Public key "
I think you gave wrong a value(or format) of "Private RSA Key" and "X509 Certificate" file when you add the key-store at Keycloak UI.
it is possible to get the public Key for RS384 by Postman and UI.
I demoed with Keycloak 18.0.0 with "ssh-keygen" & "openssl" on Ubuntu.
Generate RS384 private key and public key and certification file
ssh-keygen -t rsa -b 4096 -E SHA384 -m PEM -P "" -f RS384.key
openssl req -new -x509 -key RS384.key -out RS384-cert.pem -days 360
it will create three files
RS384-cert.pem <- certification file
RS384.key <- private key
RS384.key.pub <- public key
Add Keystore with 1.'s files
New Keystore will be created
Can get Key by Postman
can compare public key between UI and openssl generated it.
you can check API call value and JWT creator web site
with KID and public key
https://russelldavies.github.io/jwk-creator/
The issue is I did not add "use":"sig" in the JWKS that is kid is not available

Retrieving information from the payload of a JWT in a service

The context : kubernet + isio + gateway (HTTPS/JWT) + nodejs service.
Service call :
USER_TOKEN=$(< user.jwt); curl -H "Host: service.server.io" -H "Authorization: Bearer $USER_TOKEN" https://service.server.io:443/feature --cacert service-server.crt --resolve service.server.io:443:10.109.30.39
Everything works well, but I would like to retrieve my user ID stored in the JWT payload { user_uid: xxxxx, group: xxx }.
Ideally, I would like the "user_id" to be injected into the request header so that I can retrieve it from the node.
Header:
"host":"service.server.io"
"user-agent":"curl/7.68.0","accept":"/"
"x-forwarded-for":"172.17.0.1"
"x-forwarded-proto":"https"
"x-request-id":"6783b5c0-6d20-4702-98d7-b04732de90cc"
"x-envoy-attempt-count":"1"
"x-envoy-internal":"true"
"x-forwarded-client-cert":"By=spiffe://cluster.local/ns/server/sa/service;Hash=118639f45b8873d8a38fb947736dbcfb974d12ae54ad46a8ba391ef9130f289e;Subject="";URI=spiffe://cluster.local/ns/istio-system/sa/istio-ingressgateway-service-account"
"x-b3-traceid":"8119e0fa2fc19699f301e1c7035e099d"
"x-b3-spanid":"2910ce2ce185e82b"
"x-b3-parentspanid":"f301e1c7035e099d"
"x-b3-sampled":"0"
Thank you for your help,
WCDR
Thanks Istio doc ^_^
outputPayloadToHeader string This field specifies the header name to output a successfully verified JWT payload to the backend. The forwarded data is base64_encoded(jwt_payload_in_JSON). If it is not specified, the payload will not be emitted.
Edit yaml file:
kind: "RequestAuthentication"
Under jws at the same level add: outputPayloadToHeader: x-jwt
Apply changes...
Now a new header input is available "x-jwt" it is a base64 input that contains the payload.

Why is the CouchDB JWT Authentication with Auth0 not working for me?

I have been trying to use the JWT authentication method in CouchDB together with Auth0. Following the Documentation at https://docs.couchdb.org/en/stable/api/server/authn.html#jwt-authentication , i added the authentication_handlers in my default.ini file and configured jwt_auth and jwt_keys like this:
[jwt_auth]
; List of claims to validate
required_claims = alg,kid,sub
[jwt_keys]
rsa:<kid> = -----BEGIN PUBLIC KEY-----\n
<PublicKey>
\n-----END PUBLIC KEY-----\n
I got the kid and the public key from Auth0 (https://[myDomain]/.well-known/jwks.json). Now when i request the JWT Token and add it to the CouchDB request against the _session endpoint i get the following response:
{
"ok": true,
"userCtx": {
"name": null,
"roles": []
},
"info": {
"authentication_handlers": [
"cookie",
"default"
]
}
}
I feel like i am doing something wrong within the default.ini file. Can anyone help me?
It looks like you haven't enabled JWT authentication in CouchDB. I say this because this:
"info": {
"authentication_handlers": [
"cookie",
"default"
]
}
should also include "jwt".
To get that, the [chttpd] block in CouchDB config should include:
{chttpd_auth, jwt_authentication_handler}
In addition, I don't think you need to have those three required claims listed. I got this working just the other day, and as those are required by Couch, you don't need to list them. Indeed, when I listed any one of them I got an error about "duplicate requirement" or something.
Also, make sure there's no iss (issuer) claim in the JWT. This is an issue likely to be fixed in a future release, but as of the time of writing, to get this to work with Couch 3.1 I had to explicitly make sure there was no iss claim.
More details in this issue.
So this is pretty embarrassing but my problem was that I didn't enter the public key in PEM format, so all i had to do was to use this command:
curl https://[myDomain]/pem -s | openssl x509 -pubkey -noout
to get the PEM format and use it to configure the CouchDB.

illegal base64 data at input byte 8

Trying to apply deployment.yaml but I got error illegal base64 data at input byte 8.
In my config.json
"auths": {
"https://index.docker.io/v1/": {
"auth": "16c...ad7"
}
}
I have put token from the docker hub
Register the secret
kubectl create secret generic regcred --from-file=.dockerconfigjson=C:\Users\Herman\.docker\config.json --type=kubernetes.io/dockerconfigjson
in my .yaml my imagePullSecrets: - name: regcred
anybody can help?
In my case, the the oauth2accesstoken part wasn't base64 encoded as well. So once I made sure that part was also base64 encoded, along with the token in the same string, it worked.
Example Setup for oAuth and GCR
ACCESS_TOKEN=$(gcloud auth print-access-token)
export BASE_64_GCR_AUTH_TOKEN=$(echo "oauth2accesstoken:${ACCESS_TOKEN}" | base64 -w 0)