Change Terraform over to the new authn-gcp conjur authenticator

[cmm-cisco]

• Make sure gcp-hackers has permissions to use it

How To Use The Conjur GCP Authenticator

The GCP authenticator
is a secure method for workloads running on the Google Cloud Platform to
authenticate to Conjur using a unique short-term
identity token,
not an access token, signed for a Google Service Account.

Note

Only Google Service Accounts are supported by this authenticator. It cannot be
used directly by users. You absolutely can impersonate an authorized
service account, with the GCP authenticator provided you have adequate
IAM permissions. This is discussed later.

What is the difference between a Google identity token and an access token?

The easiest way to keep them straight is to remember that one is a ID card
and the other is a Master Key. In Google Cloud, mixing these up is the most
common cause of "401 Unauthorized" or "403 Forbidden" errors. Here is the
breakdown of how they differ and exactly when to use each.

Differences Between Identity Tokens and Access Tokens

Feature	Identity Token (ID Token)	Access Token
Protocol	OpenID Connect (OIDC)	OAuth 2.0
Purpose	Authentication: "Who are you?"	Authorization: "What are you allowed to do?"
Audience	Your application (the "Client")	The API or Resource (the "Server")
Format	Always a JWT (can be decoded)	Usually Opaque (looks like gibberish)
Key Info	User’s email, name, and unique ID	Scopes (permissions like cloud-platform)

When to use an Identity Token

You use an ID Token when your goal is to prove to a service that you (or
your service account) are a specific identity.

Crucial Rule: If you are trying to "log in" or "hit a service URL," like we're
doing with the Conjur GCP Authenticator, you need an ID Token.

When to use an Access Token

You use an Access Token when you want to call a Google API to perform an
action on a resource (like creating a bucket or starting a VM).

Crucial Rule: If you are calling *.googleapis.com, you almost certainly
need an Access Token.

How They Work Together

In a typical Google Cloud environment, a Service Account often needs to all of
these:

1. Authentication: The service account provides its credentials to Google’s Auth server.
2. Issuance: Google sends back an ID Token (to identify the service) and an Access Token (to authorize it to work with Google APIs).

Common Gotcha: "The Wrong Audience" and Workaround

An ID Token contains an aud (audience) claim. If you generate an ID token for
"Service A" but try to use it to call "Service B," Google (or Conjur) will
reject it. The token must be minted specifically for the endpoint you are
calling.

Conjur specifically uses the aud claim to prime the GCP authenticator
to expect a specific host principal to grant access. The validated service
account E-mail in the token paylod and JWT digital signature must validate, or
access is denied and a 401 HTTP error is returned.

Can I create an identity token for my own user and change the audience claim?

The short answer is: No, not directly through the standard Google OAuth 2.0
flow.

If you are using a standard User Account (your @cisco.com,
.web@cisco.com web admin account, .gen@cisco.com generic account)
and performing a typical "Login with Google" flow, Google sets the
aud (audience) to your OAuth 2.0 Client ID. You cannot manually change
this to a custom URL during the standard authorization request.

However, there is a workaround used by developers when they need a user to call
a protected Google Cloud service. That workaround is to impersonate a service
account.

Why This Limitation Exists

Identity tokens for users are designed for Authentication to an application.
When you create a Client ID in the Google Cloud Console, Google assumes that
that specific application is the audience. Allowing a user to arbitrarily set
the audience would create a security risk called
Token Substitution,
where a malicious site could trick you into signing a token meant for a sensitive
backend service.

The Workaround: Service Account Impersonation

If you are a developer and you need to get an ID token with a specific aud
(like as used for the Conjur GCP Authenticator) while logged in as yourself, you
must impersonate a Service Account.

How to impersonate via gcloud CLI

You can use the gcloud tool to tell Google: "I am [user], but please act as
[service-account] and generate an ID token for [audience]."

gcloud auth print-identity-token \
    --impersonate-service-account="my-service-account@my-project-id.iam.gserviceaccount.com" \
    --audiences="my-audience"

How to retrieve an identity token via cURL

curl -s -X POST \
  -H "Authorization: Bearer $(gcloud auth print-access-token)" \
  -H "Content-Type: application/json; charset=utf-8" \
  --data '{"audience":"my-audience","includeEmail": "true"}' \
  "https://iamcredentials.googleapis.com/v1/projects/-/serviceAccounts/my-service-account@my-project-id.iam.gserviceaccount.com:generateIdToken" |
    jq -r .token

Requirements for this to work:

1. IAM Role: Your user account must have the roles/iam.serviceAccountTokenCreator
   (or roles/serviceAccountOpenIdTokenCreator) role on that specific service account.
2. API Enabled: The Service Account Credentials API
   (iamcredentials.googleapis.com) must be enabled in your current project.

To allow a user to impersonate a service account, you must grant them specific
roles on the service account resource itself (or at the project level,
though the service account level follows the principle of least privilege).

Required IAM Roles

Depending on what kind of token you need (as we discussed with Access vs.
Identity tokens), you need one of the following:

Role Name	IAM ID	Purpose
Service Account Token Creator	roles/iam.serviceAccountTokenCreator	Most Permissive. Allows the user to generate both OAuth 2.0 access tokens and OIDC identity tokens.
Service Account OpenID Connect Identity Token Creator	roles/iam.serviceAccountOpenIdTokenCreator	A more restrictive role that only allows creating OIDC identity tokens. Useful to grant authority to create ID tokens without granting access to the service account to make requests of the Google Cloud APIs. Unfortunately, the gcloud CLI needs the broader permissions to impersonate a service account as a user. Using cURL against the API directly doesn't require the broader permissions.

How to Grant the Required IAM Role via CLI

To give yourself permission to impersonate a specific service account, run:

gcloud iam service-accounts add-iam-policy-binding \
    <service-account-email> \
    --member="user:<your-user-id>@cisco.com" \
    --role="roles/iam.serviceAccountTokenCreator"

To verify the change was made:

gcloud iam service-accounts get-iam-policy \
    <service-account-email>

Note

Don't confuse Service Account Token Creators with Service Account Users
There is a common mix-up between Token Creator and Service Account User (roles/iam.serviceAccountUser):

• Token Creator: Allows you to act as the service account (impersonation).
• Service Account User: Allows you to attach the service account to a resource (like a VM or a Cloud Run service). It does not let you generate tokens on your local machine.

For Conjur, this format is used for the audience claim:

conjur/<account>/host/<organization>/<namespace-name>/<host-api-principal>

Create a Conjur Access Token

Acting as a Service Account

Putting it all together to swap a GCP service-account identity token for a
Conjur access token and set up the environment:

conjur init -u https://conjur-prod.cisco.com -a cisco --force

export CONJUR_AUTHN_TOKEN=$(curl -s -X POST \
  https://conjur-prod.cisco.com/authn-gcp/cisco/authenticate \
  --header 'Content-Type: application/x-www-form-urlencoded' \
  --header 'Accept-Encoding: base64' \
  --data-urlencode "jwt=`gcloud auth print-identity-token \
    --token-format=full \
    --audiences=conjur/cisco/host/sto/asig_le/gcf-by-sa-email`" |
      base64 -d)

conjur whoami
{
  "client_ip": "10.37.64.205",
  "user_agent": "Go-http-client/2.0",
  "account": "cisco",
  "username": "host/sto/asig_le/gcf-by-sa-email",
  "token_issued_at": "2026-03-28T21:37:04.000+00:00"
}

Choose: Secrets Manager Self-Hosted when prompted.

Note

--token-format=full enables inclusion of the email, email_verified and
google objects, which Conjur requires for authentication. It's only used with
Service Accounts. Users impersonating service accounts can't use
--token-format=full. Instead they specify --include-email.

As a Service Account, e.g. running in a GCE instance:

gcloud auth print-identity-token | cut -d '.' -f 2 | base64 -d | jq .
{
  "aud": "32555940559.apps.googleusercontent.com",
  "azp": "102776097938891794166",
  "exp": 1774729480,
  "iat": 1774725880,
  "iss": "https://accounts.google.com",
  "sub": "102776097938891794166"
}

gcloud auth print-identity-token --token-format=full | cut -d '.' -f 2 | base64 -d | jq .
{
  "aud": "32555940559.apps.googleusercontent.com",
  "azp": "102776097938891794166",
  "email": "618440573010-compute@developer.gserviceaccount.com",
  "email_verified": true,
  "exp": 1774729568,
  "google": {
    "compute_engine": {
      "instance_creation_timestamp": 1768105995,
      "instance_id": "2070053074435946989",
      "instance_name": "cmm",
      "project_id": "gcp-asigaurynccigcp-nprd-37319",
      "project_number": 618440573010,
      "zone": "us-east1-c"
    }
  },
  "iat": 1774725968,
  "iss": "https://accounts.google.com",
  "sub": "102776097938891794166"
}

Acting as a User

Swap a GCP user account identity token for a Conjur access token while
impersonating a service account:

conjur init -u https://conjur-prod.cisco.com -a cisco --force

export CONJUR_AUTHN_TOKEN=$(curl -s -X POST \
  https://conjur-prod.cisco.com/authn-gcp/cisco/authenticate \
  --header 'Content-Type: application/x-www-form-urlencoded' \
  --header 'Accept-Encoding: base64' \
  --data-urlencode "jwt=`gcloud auth print-identity-token \
    --impersonate-service-account=618440573010-compute@developer.gserviceaccount.com \
    --audiences=conjur/cisco/host/sto/asig_le/gcf-by-sa-email \
    --include-email`" |
      base64 -d)

conjur whoami
{
  "client_ip": "10.26.164.245",
  "user_agent": "Go-http-client/1.1",
  "account": "cisco",
  "username": "host/sto/asig_le/gcf-by-sa-email",
  "token_issued_at": "2026-03-28T21:40:14.000+00:00"
}      

References

• Create short-lived credentials for a service account
• Service account impersonation
• Roles for service account authentication
• Use service account impersonation

---

[cmm-cisco]

Opened case to enable authn-gcp with becomingahacker, INC10839988. Case was resolved, but reopened because the bulk/batch endpoint (and the CLI) does not work. OpenTofu and cURL do work.

---

First, working with the CLI, get a CONJUR_AUTHN_TOKEN, base64 decoded:

cmm_cisco_com@cmm-test:~$ export CONJUR_AUTHN_TOKEN=$(curl -s -X POST \
https://conjur-prod.cisco.com/authn-gcp/cisco/authenticate \
--header 'Content-Type: application/x-www-form-urlencoded' \
--header 'Accept-Encoding: base64' \
--data-urlencode "jwt=`gcloud auth print-identity-token \
--token-format=full \
--audiences=conjur/cisco/host/sto/becomingahacker/cmm-test`" | base64 -d)

Whoami looks right:

cmm_cisco_com@cmm-test:~$ conjur whoami
{
"client_ip": "10.37.64.145",
"user_agent": "Go-http-client/2.0",
"account": "cisco",
"username": "host/sto/becomingahacker/cmm-test",
"token_issued_at": "2026-05-12T14:52:39.000+00:00"
}

Can list:

cmm_cisco_com@cmm-test:~$ conjur list
[
"cisco:policy:sto/becomingahacker/secret",
"cisco:policy:sto/becomingahacker/secret/common",
"cisco:policy:sto/becomingahacker/secret/common/becomingahacker.com",
"cisco:policy:sto/becomingahacker/secret/common/becomingahacker.com/prod",
"cisco:policy:sto/becomingahacker/secret/common/becomingahacker.com/prod/device",
"cisco:policy:sto/becomingahacker/secret/common/becomingahacker.com/prod/device/ltrsec-2034-clamer26",
...
"cisco:variable:sto/becomingahacker/secret/ping",
"cisco:webservice:conjur/authn-gcp",
"cisco:webservice:conjur/authn-gcp/cisco"
]

Unable to read a variable:

cmm_cisco_com@cmm-test:~$ conjur variable get -d -d -d --id 'sto/becomingahacker/secret/ping'
GET /secrets/?variable_ids=cisco%3Avariable%3Asto%2Fbecomingahacker%2Fsecret%2Fping HTTP/1.1
Host: conjur-prod.cisco.com
User-Agent: Go-http-client/1.1
Accept-Encoding: base64
Authorization: [REDACTED]
X-Cybr-Telemetry: [omitted]



HTTP/2.0 403 Forbidden
Content-Length: 118
Content-Type: text/html
Date: Tue, 12 May 2026 14:52:57 GMT
Server: awselb/2.0

<html>
<head><title>403 Forbidden</title></head>
<body>
<center><h1>403 Forbidden</h1></center>
</body>
</html>



ERROR

<Html> <head><title>403 Forbidden</title></head> <body> <center><h1>403 Forbidden</h1></center> </body> </html>.

Perhaps I have the format wrong?

cmm_cisco_com@cmm-test:~$ conjur resource show cisco:variable:sto/becomingahacker/secret/ping
{
"annotations": [],
"created_at": "2023-12-20T19:27:35.116+00:00",
"id": "cisco:variable:sto/becomingahacker/secret/ping",
"owner": "cisco:policy:sto/becomingahacker/secret",
"permissions": [],
"policy": "cisco:policy:sto/becomingahacker",
"replication_sets": [],
"secrets": [
{
"expires_at": null,
"replication_sets": [],
"version": 1
}
]
}

cmm_cisco_com@cmm-test:~$ conjur variable get -i 'cisco:variable:sto/becomingahacker/secret/ping'

ERROR

<Html> <head><title>403 Forbidden</title></head> <body> <center><h1>403 Forbidden</h1></center> </body> </html>.

Next, to work with cURL get a token, with base64 encoding intact:

cmm_cisco_com@cmm-test:~$ export TOKEN=$(curl -s -X POST \ST \
https://conjur-prod.cisco.com/authn-gcp/cisco/authenticate \
--header 'Content-Type: application/x-www-form-urlencoded' \
--header 'Accept-Encoding: base64' \
--data-urlencode "jwt=`gcloud auth print-identity-token \
--token-format=full \
--audiences=conjur/cisco/host/sto/becomingahacker/cmm-test`")

cmm_cisco_com@cmm-test:~$ curl -vvv --header "Authorization: Token token=\"$TOKEN\"" https://conjur-prod.cisco.com/secrets/cisco/variable/sto%2Fbecomingahacker%2Fsecret%2Fping
* Trying 166.117.165.240:443...
* Connected to conjur-prod.cisco.com (166.117.165.240) port 443 (#0)
* ALPN: offers h2,http/1.1
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* CAfile: /etc/ssl/certs/ca-certificates.crt
* CApath: /etc/ssl/certs
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
* TLSv1.3 (IN), TLS handshake, Finished (20):
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.3 (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / TLS_AES_128_GCM_SHA256
* ALPN: server accepted h2
* Server certificate:
* subject: C=US; ST=California; L=San Jose; O=Cisco Systems Inc.; CN=conjur-prod.cisco.com
* start date: Apr 30 02:28:43 2026 GMT
* expire date: Nov 15 02:27:43 2026 GMT
* subjectAltName: host "conjur-prod.cisco.com" matched cert's "conjur-prod.cisco.com"
* issuer: C=US; O=IdenTrust; OU=HydrantID Trusted Certificate Service; CN=HydrantID Server CA O1
* SSL certificate verify ok.
* using HTTP/2
* h2h3 [:method: GET]
* h2h3 [:path: /secrets/cisco/variable/sto%2Fbecomingahacker%2Fsecret%2Fping]
* h2h3 [:scheme: https]
* h2h3 [:authority: conjur-prod.cisco.com]
* h2h3 [user-agent: curl/7.88.1]
* h2h3 [accept: */*]
* h2h3 [authorization: Token token="eyJwcm[omitted]"]
* Using Stream ID: 1 (easy handle 0x564eead69560)
> GET /secrets/cisco/variable/sto%2Fbecomingahacker%2Fsecret%2Fping HTTP/2
> Host: conjur-prod.cisco.com
> user-agent: curl/7.88.1
> accept: */*
> authorization: Token token="eyJwcm[omitted]"
>
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
< HTTP/2 200
< date: Tue, 12 May 2026 15:04:29 GMT
< content-type: application/octet-stream
< content-length: 4
< server: nginx
< x-frame-options: SAMEORIGIN
< x-xss-protection: 1; mode=block
< x-content-type-options: nosniff
< x-download-options: noopen
< x-permitted-cross-domain-policies: none
< referrer-policy: strict-origin-when-cross-origin
< content-disposition: attachment
< content-transfer-encoding: binary
< vary: Accept
< cache-control: private
< etag: W/"9795c5ff8937f23526ccb207a5684c1f"
< x-request-id: eb5dd30d-6d38-43ac-8cee-207f288d748e
< x-runtime: 0.009620
<
* Connection #0 to host conjur-prod.cisco.com left intact
pong

I'm not dependent on the CLI, but hopefully this might have uncovered something.