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’s read baseline is a set of narrow, ready-made Google roles, each covering one area, for example:

roles/cloudasset.viewer                : the project's asset inventory
roles/compute.viewer                   : Compute Engine resources
roles/monitoring.viewer                : usage metrics
roles/bigquery.dataViewer + jobUser    : billing export data in BigQuery
roles/container.viewer                 : GKE clusters

There is no broad roles/viewer and no custom role. To let it act, the read_write level adds more of Google’s ready-made roles, such as:

roles/compute.instanceAdmin.v1         : start/stop Compute Engine instances
roles/container.clusterAdmin           : GKE cluster and node pool changes
roles/cloudsql.editor                  : start/stop Cloud SQL instances

The setup guide in the product lists the exact roles for the level you choose.

GCP: connecting

Two paths:

One-Click Connect, which is the recommended route. You sign in with Google and pick the project. ZopNight then creates a dedicated service account in that project (zopnight-sa@<project>.iam.gserviceaccount.com), manages its key for you, and binds the roles for the permission level you chose. The Google user you sign in with must be able to manage IAM on the project. You never download or handle a key file.

The key file. You create the service account yourself, grant it the roles, download its JSON key, and upload that to ZopNight. The file is the credential, so it goes straight into the vault described in L1. Its weakness is that the file does not expire: changing it means generating a new one and using Update credentials.

You can switch an account between the two later without losing anything attached to it.

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 writes, ZopNight uses its own custom roles rather than Microsoft’s built-in ones:

Zopnight Write Access                 : VM start/stop/deallocate and other actions
Zopnight AKS Access                   : AKS cluster scheduling

Azure: connecting

Three values are needed:

Tenant ID           : the Azure AD tenant the customer uses
Application ID       : the registered app's UUID
Client secret        : the app's client secret (Service Principal, recommended)
                      : OR: workload identity federation (the alternative)

The recommended method is the service principal with a client secret, which goes into the vault. The alternative is Workload Identity Federation: Azure calls it federated credentials, and it removes the stored secret.

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.

In ZopNight you then connect the account at tenant scope. ZopNight finds every subscription the service principal can reach and adds each one as a child account under it. A subscription-scoped account covers just that one subscription.

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 policies      Narrow viewer roles       Reader + Cost Reader
Writes (read_write)    Write policies     Predefined roles          Custom roles
Trust mechanism        WIF-Assume Role     One-Click (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 "One-Click Connect" (recommended) and the permission level
T+2 min   Sign in with Google and consent
T+3 min   Pick the project from the list ZopNight shows
T+4 min   ZopNight creates zopnight-sa in the project and binds the roles
T+4 min   The credential is verified live against Google
T+5 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 a client secret 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 + secret into ZopNight
T+5 min   ZopNight verifies the credential live against Azure
T+6 min   Account marked Active; discovery preview begins

Five to six minutes per cloud. Neither path asks you to build anything in your own cloud beyond the roles.

3. Hands-on (7 min)

Connect a GCP project or Azure subscription:

GCP:
1. In ZopNight, choose One-Click Connect when adding a GCP project.
2. Sign in with a Google user who can manage IAM on a sandbox project.
3. Pick the project and the permission level.
4. Check in the GCP console that zopnight-sa now exists with its roles.
5. Verify connection: the account should show Active within a minute.

Azure:
1. In ZopNight, choose Service Principal when adding an Azure subscription.
2. Create the App Registration and a client secret.
3. Assign Reader and Cost Management Reader at the subscription or MG scope.
4. Paste tenant ID + app ID + client secret into 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 recommended connection methods for GCP and Azure are:

A. GCP: a customer-built Workload Identity pool. Azure: federated credentials
B. GCP: One-Click Connect with Google sign-in. Azure: a service principal with a secret
C. GCP: a service account key file. Azure: a username and password for a user account
D. GCP: an SSH key on each VM. Azure: a certificate uploaded to each subscription

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: narrow viewer roles 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: One-Click Connect, or a service account key
• Add Azure: service principal (or 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)
• T4.M4.2: SAML, Google OAuth, GitHub OAuth

Glossary terms touched

Service account · Service principal · Workload identity federation · Management Group