GCP & Azure: service accounts and SPNs

Outcome

By the end of this lesson, you will be able to configure GCP service accounts and Azure service principals for ZopNight and identify the GCP and Azure equivalents of the AWS read-mostly pattern.

1. Concept

AWS, Google and Microsoft each have their own word for “an identity that belongs to a program rather than a person”. The words differ. The arrangement underneath is the same one you saw for AWS: read everything, change only what you allowed.

Google: the service account

Google calls it a service account: a permanent identity that software uses instead of a person logging in. ZopNight asks for one carrying two roles:

roles/viewer                           : broad read across the project
roles/billing.viewer                   : read access to billing data

To let it act, you add either one of Google’s ready-made roles or, better, a role you define yourself with only the actions you want:

roles/compute.instanceAdmin.v1         : full Compute Engine management (CAUTION)
                                         : typically replaced by a custom role
                                         : with only the start/stop / suspend / resume
                                         : actions

A custom "ZopNight Scheduler" role with:
  compute.instances.start
  compute.instances.stop
  compute.instances.suspend
  compute.instances.resume
  container.clusters.update
... (similar narrow list for GKE workloads)

GCP: connecting

Two paths:

The key file. You create the service account, download its JSON key, and upload that to ZopNight. The file is the credential, so it goes straight into the vault described in L1. It is the quicker route, and its weakness is that the file does not expire: changing it means generating a new one and uploading it again.

Workload Identity Federation, which is the better route. Instead of handing over a file, you tell Google to trust ZopNight’s identity directly. When ZopNight needs to do something, it proves who it is and Google issues a token good for about an hour. Nothing permanent is ever stored.

Setup steps for Workload Identity:
1. Create a Workload Identity Pool in the customer's GCP project
2. Create a Provider in the pool pointing at ZopNight's OIDC issuer
3. Bind the pool's principal to the service account
4. Configure ZopNight Cloud Account with the project ID and pool ID

No file changes hands, and there is nothing sitting in a vault waiting to leak.

Google: when you have many projects

A company of any size runs dozens of Google projects, usually one per environment or per business unit. Attach the permission at the organisation level and ZopNight sees every project under it in one go.

If that is more than you want to give, attach it to specific folders or projects instead. Everything outside stays invisible.

Microsoft: the service principal

Azure has you register an application, and that application gets a service principal, which is its identity when it runs. ZopNight asks for one with two roles:

Reader                                : broad read at subscription scope
Cost Management Reader                : read access to Cost Management data

For scoped writes:

Virtual Machine Contributor           : VM start/stop/deallocate
AKS Cluster Admin                     : for AKS workload scheduling
Custom role "ZopNight Scheduler"      : preferred, narrow start/stop/deallocate

Azure: connecting

Three values are needed:

Tenant ID           : the Azure AD tenant the customer uses
Application ID       : the registered app's UUID
Client secret        : a long-lived credential (or use certificate)
                      : OR: workload identity federation (preferred)

The client secret goes into the vault. As with Google, the better route is federation: Azure calls it federated credentials, and it removes the permanent secret entirely.

Microsoft: when you have many subscriptions

Azure stacks management groups at the top with subscriptions underneath. Where you attach the permission decides what ZopNight can see.

Tenant
  Management Group: root
    Management Group: production
      Subscription: prod-eu-1
      Subscription: prod-us-1
    Management Group: non-production
      Subscription: dev
      Subscription: stage

Give Reader at root and ZopNight sees every subscription. Give it at non-production and ZopNight sees dev and stage, and nothing else. It is the same choice you make on AWS between the whole organisation and one account at a time.

The same picture three times

LAYER                  AWS                GCP                       AZURE
─────────────────────────────────────────────────────────────────────────────
Identity primitive     IAM Role           Service Account            Service Principal
Multi-account scope    AWS Organization    GCP Organization          Management Group
Read baseline          Read-only policy   roles/viewer + billing    Reader + Cost Reader
Scoped writes          Tagged actions     Custom role               Custom role
Trust mechanism        AssumeRole + ExtID  WI Federation (or key)   App + Secret (or WIF)

Read that table downwards and the three clouds look alike, because they are. Learn one properly and the other two are a matter of looking up the local names.

2. Demo

GCP connection walkthrough:

T+0       ZopNight → Cloud Accounts → Add GCP Account
T+1 min   Choose "Workload Identity Federation" (recommended)
T+2 min   ZopNight displays terraform snippet for WI Pool + Provider
T+3 min   Customer applies terraform in their GCP project
T+5 min   Customer pastes project ID + pool resource name back to ZopNight
T+6 min   ZopNight validates via Identity Aware Proxy
T+7 min   Account marked Active; discovery preview begins

Azure connection walkthrough:

T+0       ZopNight → Cloud Accounts → Add Azure Account
T+1 min   Customer creates App Registration in Azure AD portal
T+2 min   Customer creates federated credential under the app
T+3 min   Customer assigns Reader + Cost Mgmt Reader at MG/Sub scope
T+4 min   Customer pastes tenant ID + app ID into ZopNight
T+5 min   ZopNight validates via OAuth2 / federated token exchange
T+6 min   Account marked Active; discovery preview begins

Six to seven minutes per cloud. Both paths use workload identity federation as the modern default.

3. Hands-on (7 min)

Connect a GCP project or Azure subscription:

GCP:
1. In ZopNight, choose Workload Identity Federation when adding a GCP project.
2. Apply the offered terraform in a sandbox GCP project.
3. Bind ZopNight's principal to a service account with roles/viewer + billing.
4. Paste the project ID and pool resource name back to ZopNight.
5. Verify connection: should take under 60 seconds after the WI pool is set up.

Azure:
1. In ZopNight, choose Federated Credential when adding an Azure subscription.
2. Create the App Registration with the federated credential pointing at ZopNight.
3. Assign Reader and Cost Management Reader at the subscription or MG scope.
4. Paste tenant ID + app ID back to ZopNight.
5. Verify connection: should take under 60 seconds after permissions propagate.

If either fails, open Permission Visibility (L4) to read which specific service
the credential cannot access. The error path is informative.

4. Knowledge check

Q1

The modern recommended path for GCP and Azure credentials is:

A. Long-lived service account key files and client secrets, which are far simpler to set up and which never need any rotating over their whole lifetime
B. SSH keys
C. Workload Identity Federation (GCP) and Federated Credentials (Azure); no long-lived credentials in the vault, short-lived tokens fetched at call time
D. Username and password

Q2

For an Azure tenant with 15 subscriptions across two management groups, the most operationally efficient way to give ZopNight broad discovery access is:

A. 15 service principal grants, one per subscription
B. Use ARM templates
C. Wait for Microsoft to do it
D. Assign Reader at the management group scope

Q3

The “read-mostly” model maps to GCP and Azure as:

A. Only works on AWS
B. Same architecture: roles/viewer + billing.viewer on GCP, Reader + Cost Mgmt Reader on Azure: both are read-only baselines
C. Only works on the AWS-compatible clouds, since the other two do not expose any equivalent role model of their own
D. Different on each cloud

5. Apply

ZopNight’s connection wizards offer cloud-specific guidance:

• Add GCP: workload identity flow with terraform snippet
• Add Azure: federated credential flow with portal walkthrough
• Documentation: full step-by-step for each path

Connection-time errors map cleanly to permission errors via the Permission Visibility drawer (L4 next).

Related lessons

• L4: Permission Visibility (next)
• T3.M3.2: SAML, Google OAuth, GitHub OAuth

Glossary terms touched

Service Account (GCP) · Service Principal (Azure) · Workload Identity Federation · Management Group · App Registration