Skip to main content
Question

Using Chronicle API v1beta with SA impersonation

  • March 5, 2026
  • 5 replies
  • 180 views

u6004331239
Forum|alt.badge.img+1

If I impersonate the SA by ACCESS_TOKEN=$(gcloud auth print-access-token --impersonate-service-account=secops-sa@project-here.iam.gserviceaccount.com --scopes="https://www.googleapis.com/auth/cloud-platform") and fetch the instance data by curl -H "Authorization: Bearer $ACCESS_TOKEN" "https://chronicle.us.rep.googleapis.com/v1beta/projects/123456789012/locations/us/instances/1a1a1a1a-1a1a-1a1a-1a1a-1a1a1a1a1a1a/", the request is successful and the response contains the wanted data.
However, if I attempt to curl -H "Authorization: Bearer $ACCESS_TOKEN" "https://chronicle.us.rep.googleapis.com/v1beta/projects/123456789012/locations/us/instances/1a1a1a1a-1a1a-1a1a-1a1a-1a1a1a1a1a1a/cases", the response is


{

  "error": {

    "code": 401,

    "message": "Request is missing required authentication credential. Expected OAuth 2 access token, login cookie or other valid authentication credential. See https://developers.google.com/identity/sign-in/web/devconsole-project.",

    "status": "UNAUTHENTICATED"

  }

}

Looks like the v1 API works with the impersonation, but most of the resources under v1beta and v1alpha do not and we get the error message. If I use my own GCP identity (which is a Chronicle admin) the request  curl -H "Authorization: Bearer $ACCESS_TOKEN" "https://chronicle.us.rep.googleapis.com/v1beta/projects/123456789012/locations/us/instances/1a1a1a1a-1a1a-1a1a-1a1a-1a1a1a1a1a1a/cases" works (after ACCESS_TOKEN=$(gcloud auth print-access-token)). I also gave the SA the same privileges to Chronicle as I have (an IAM role) and that did not solve the issue.

There may be some small changes in authentication & authorization between e.g. v1 and v1beta when using SA impersonation. What these would be? Are there some workarounds, tricks or tips for fixing this issue? The intent is to develop a small tool which runs in Cloud Functions. If SA impersonation does not work in dev env from dev endpoint, I'm not sure if it will work from a Cloud Function either.

I have ensured that the SA has the necessary (GCP IAM) permissions for accessing the cases resource. Chronicle API access should be controllable with GCP IAM.

5 replies

hzmndt
Staff
Forum|alt.badge.img+11
  • Staff
  • March 5, 2026

@u6004331239 i tried seems okay for v1beta and v1alpha, but no v1 

API Version     | HTTP Status Code   | Status Message
------------------------------------------------------------
v1alpha         | 200                | OK
v1beta          | 200                | OK
v1              | 404                | Not Found


API tested - url = f"https://{location}-chronicle.googleapis.com/{version}/projects/{project}/locations/{location}/instances/{instance_id}/cases


u6004331239
Forum|alt.badge.img+1
  • Author
  • March 5, 2026

@hzmndt thanks for testing 🙏 Hmm maybe something is off with the SecOps instance’s “attachment” with the project 🤔 


_eo
Forum|alt.badge.img+5
  • Bronze 4
  • March 5, 2026

I’m having a similar issue. I am using a service account key file and when I hit the /cases endpoint for any version, it doesn’t work. However, when i hit the /rule endpoint on all 3 versions I get info back. The service account has chronicle admin permissions, so it shouldn’t be a permissions issue.


u6004331239
Forum|alt.badge.img+1
  • Author
  • March 16, 2026

@_eo thanks for confirming that I’m not the only one with this kind of issue. I found a solution for this:

 

create a new, separate IAM Role mapping specifically for the SA under your SecOps SOAR settings:
-> Go to: Settings > SOAR Settings > Advanced > IAM Role Mappings
-> Click + Add Mapping

 

Fill in the details:
-> IDP Role / IAM Role: Enter a descriptive name (e.g., ServiceAccountAPIAccess).
-> Group Members: Add the Service Account email here (remember to press Enter after adding the email so the value gets submitted to the field)
-> Permission Groups: Select Administrators
-> SOC Roles: Choose your standard SOC Role
-> Environments: Choose your standard Environment
-> Click Save

 

I have not yet tested if the SA now has full admin privileges in the instance, or if the GCP IAM settings restrict privileges at all. If it has full admin privileges, that needs to be fixed somehow.


u6004331239
Forum|alt.badge.img+1
  • Author
  • March 16, 2026

I can confirm that when the SA’s GCP IAM role did not have the chronicle.connectorEvents.get permission, the SA failed to fetch connector events. After adding chronicle.connectorEvents.get to the role, fetching these succeeded. So it did not end up being a full admin in the instance. However, I advice testing the access rights always :)