-
Notifications
You must be signed in to change notification settings - Fork 24
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
FR: add support for google OIDC tokens #46
Comments
Doesn't seem like a custom type should be necessary if they're really OIDC tokens as google claims. |
@jefferai Could you elaborate a bit more on that? |
I think what @jefferai means is that instead of having a new |
ok, we'd def want to apply selective acls to both token types |
Is there any way to prioritize this work to support generating tokens for IAP authentication? |
was looking at this for a diff reason today and decided to update it with HEAD. attached are the modifications and the working usage for if there is interest in having additional secret types based on the existing way to get access and service account jwt, the files attached to this issue at the bottom could be used as working start point (i'd submit it fully but don't know how to writeup the testcases at all)
export GOBIN=`pwd`/bin
make fmt
make dev
vault server -dev -dev-plugin-dir=./bin --log-level=debug
load plugin export VAULT_ADDR='http://localhost:8200'
export SHASUM=$(shasum -a 256 "bin/vault-plugin-secrets-gcp" | cut -d " " -f1)
vault plugin register \
-sha256="${SHASUM}" \
-command="vault-plugin-secrets-gcp" \
secret vault-plugin-secrets-gcp
vault secrets enable --plugin-name='vault-plugin-secrets-gcp' --path="gcp" plugin OIDC TokenCreate Roleset vault write gcp/roleset/my-idtoken-roleset \
project="pubsub-msg" \
secret_type="id_token" \
audience="https://foo.bar" \
bindings=-<<EOF
resource "//cloudresourcemanager.googleapis.com/projects/pubsub-msg" {
roles = []
}
EOF Create VAULT_TOKEN with policy
Copy VAULT_TOKEN to new window and access secret export VAULT_ADDR='http://localhost:8200'
export VAULT_TOKEN=s.gSREOoTDI5vGZwHQKW1w43Fl
vault read gcp/idtoken/my-idtoken-roleset
gives an id_token with {
"aud": "https://foo.bar",
"azp": "vaultmy-idtoken-rol-1626810226@pubsub-msg.iam.gserviceaccount.com",
"email": "vaultmy-idtoken-rol-1626810226@pubsub-msg.iam.gserviceaccount.com",
"email_verified": true,
"exp": 1626814203,
"iat": 1626810603,
"iss": "https://accounts.google.com",
"sub": "114468490684103952334"
} JWTAccessTokenvault write gcp/roleset/my-jwttoken-roleset \
project="pubsub-msg" \
secret_type="jwt_access_token" \
audience="https://pubsub.googleapis.com/google.pubsub.v1.Publisher" \
bindings=-<<EOF
resource "projects/pubsub-msg" {
roles = ["roles/pubsub.admin"]
}
EOF
vault policy write jwttoken-policy -<<EOF
path "gcp/jwtaccess/my-jwttoken-roleset" {
capabilities = ["read"]
}
EOF
vault token create -policy=jwttoken-policy copy export VAULT_ADDR='http://localhost:8200'
export VAULT_TOKEN=s.W73ewt7HJ8JEClRUYkx4UxaW
$ vault read gcp/jwtaccess/my-jwttoken-roleset
Key Value
--- -----
expires_at_seconds 1626814668
jwt_access_token eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCIsImtpZCI6IjZkZTBlZDI0Mzc5MmQ2MjVmNjM2MzllMzU0Njg4NDIyM2JmZGUxZmUifQ.eyJpc3MiOiJ2YXVsdG15LWp3dHRva2VuLXJvLTE2MjY4MTA3NTJAcHVic3ViLW1zZy5pYW0uZ3NlcnZpY2VhY2NvdW50LmNvbSIsImF1ZCI6Imh0dHBzOi8vZm9vLmJhciIsImV4cCI6MTYyNjgxNDY2OCwiaWF0IjoxNjI2ODExMDY4LCJzdWIiOiJ2YXVsdG15LWp3dHRva2VuLXJvLTE2MjY4MTA3NTJAcHVic3ViLW1zZy5pYW0uZ3NlcnZpY2VhY2NvdW50LmNvbSJ9.euCJI5w0_nwBICRCoyQZvKc03CxaXXbRdcLH0I_uJJj8oLsLIUITLOlkHkvZiPgcwvY5OELaWt4i04MkaY3ou6ObSp7UcxIeYqVBtPc-4gIX6sm-wHHFRT5EXHXkEX4wD8FXhxiBDduLYtoZP_Njx1IV0B1que5njN8hqgPsn917KwzuWH_7GZA1UcYxkX5Gq3O13UMk9H8-O-djM-mIaF75juiVAo77EiWfcdiDuHzgyrSWNZ0NeusGrhc9V8ZGTs28reFotnrMjMiH0Nygdd1syTJBKdgoNpN_9VOoLViXv5pGrDf5-GUXUjTyDwEUaNBJ1BV7vbLNXLvG5HsHfQ
token_ttl 59m59s gives JWTAccessToken of form {
"iss": "vaultmy-jwttoken-ro-1626810752@pubsub-msg.iam.gserviceaccount.com",
"aud": "https://pubsub.googleapis.com/google.pubsub.v1.Publisher",
"exp": 1626814668,
"iat": 1626811068,
"sub": "vaultmy-jwttoken-ro-1626810752@pubsub-msg.iam.gserviceaccount.com"
} |
feature request to add support for providing google
id_tokens
through vault.These tokens can be derived from service accounts or GCE metadata server that can then be used to authenticate against a users service on
Google Cloud Run
, cloud functions, endpoints, IAP. For more info on usecases see Authenticating using Google OpenID Connect TokensI put together a prototype of
secret_type=id_token
by directly copying the access_token implementation code, then adding an additiona flag foraudience
:https://github.com/salrashid123/vault-plugin-secrets-gcp/blob/master/README_oidc_jwt.md#run-oidc
secret_id_token.go
at that point, just read the id_token back
which includes claims:
Couple of notes:
the
bindings=
doesn't really make sense here but since there since its not realated to IAM by itself (you could apply an IAM binding later cloud run/gcf later but its orthogonal and not necessarily related to the token's capability). I'd rather just remove thebindings=
alltogether in this usecaseFYI, the snippet above used a derived service account for the id_token, you can also use the compute engine's metadata server or iamcredentils API if those underlying tokensource gets used elsewhere ref computeEngine; ref impersonate.go
The text was updated successfully, but these errors were encountered: