Credential Access Boundary is a policy language that you can use to downscope the accessing power of your GCP short-lived credentials. You can define a Credential Access Boundary that specifies which resources the short-lived credential can access, as well as an upper bound on the permissions that are available on each resource
For example, if the parent Credential that represents user Alice has Read/Write access to GCS buckets
C, you can exchange the Alice's credential for another credential that still identifies Alice but can only be used for Read against Bucket
(3/12/20): The following describes the beta release of
Credential Access Boundary (DownScoped) Tokenson Google Cloud. This API is open but not documented yet. This article is intended to demonstrate this new capability and solicit feedback on enhancements users would like to see (for that, please just leave an issue/FR on github here )
DownScoped tokens are normally used in a tokenbroker/exchange service where you can mint a new restricted token to hand to a client. The sample usage and implementations below shows how to generate a downscoped token, extract the raw access_token, and then inject the raw token in another TokenSource.
- DownScoped tokens currently only works for GCS buckets and cannot be applied yet at the bucket+prefix or object level.
- The GCS bucket must be enabled with Uniform bucket-level access
- Supported credentials: The only supported type of credential in Credential Access Boundary is OAuth2.0 access token.
You can find the git version of this article here:
Credential Access Boundary is a policy language that you can use to downscope the accessing power of your GCP…
Defining a boundary rule:
You downscope a token by transmitting that token to a google token endpoint along with a boundary rule describing the resources and roles the credential should be restricted to.
The definition of a boundary rule is just json:
AvailableResource(required) This is the GCP resource (such as organization, folder, project, bucket, etc) to which access may be allowed (and allowed to resources below that resource if applicable). It must be in the format of a GCP Resource Name.
AvailablePermissions(required) This is a list of permissions that may be allowed for use on the specified resource or resources below the specified resource. The only supported value is IAM role with syntax: "inRole:roles/storage.admin"
As an example, the following would the token to just
Exchange the token
You now need to transmit the original
access_token and the boundary rule to a google token-exchange endpoint: https://securetoken.googleapis.com/v2beta1/token. The response JSON will return a new token if the policy file is well formed.
As a quick demonstration of this capability, create two GCS buckets and acquire an
access_token that you can use to list objects in either bucket. Exchange that
access_token for another
access_token that can only be used on one of the two buckets:
- Create two buckets:
export PROJECT_ID=`gcloud config get-value core/project`export BUCKET_1=$PROJECT_ID-1
export BUCKET_2=$PROJECT_ID-1-suffixgsutil mb gs://$BUCKET_1
gsutil mb gs://$BUCKET_2
2. Create policy to only allow
3. Get existing
export TOKEN=`gcloud auth application-default print-access-token`
(the following command uses jq to parse the response):
5. Use downscoped token
Try listing bucket contents using the new token…
as you’ll see, you can access
BUCKET_2 but not
BUCKET_1 since we're using the downscoped token
At the moment, no official
google-auth-* library supports this capability. However, i've written up the implementations in the following languages which behave as if its just another credential type for any google cloud client libraries (well..just GCS at the moment).
golang: Use as
java: Use as
python: Use as
You don’t have to use any of those libraries ofcourse!. If you manually exchange and acquire a downscoped token, you can ‘just apply’ it to several existing
google-auth-* constructs that allows you to set the token:
- golang: oauth2.StaticTokenSource
- python: google.auth.credentials.Credentials.apply
- java: com.google.auth.oauth2.GoogleCredentials.create()
Note, if you use these, the static
access_token will not get refreshed automatically.
- A developer or workload (the requester) requests credentials to get access to certain GCP resources.
- The broker system identifies the service account that has access to the requested resources and gets a credential for that service account.
- Before handing off the credentials to the requestor, the broker system restricts the permissions on the credential to only what the token requester needs access to, by applying a
Credential Access Boundaryon the service account credentials by calling the CAB API.
- The broker system hands the downscoped credentials to the requester.
- The requester can now use those credentials to access GCP resources
This release has the following restrictions:
Thats it…this is just an alpha capability…do not use this in production yet!.
Again, the intent of this article is to get feedback…please add in any comments to the repo here