Vault credentials: the model

Outcome

By the end of this lesson, you will be able to describe how ZopNight stores cloud credentials and explain the four properties of the vault model.

1. Concept

Every connected cloud account comes with a credential: an AWS role, a Google service account, an Azure service principal. ZopNight has to keep that credential somewhere and use it to talk to your cloud.

Where it keeps it is called the vault, and four things are true of it.

1. It is encrypted, with a key kept somewhere else

Credentials are stored encrypted, using AES-256-GCM. Only one part of ZopNight, its configuration service, holds the key and can decrypt them. Every other part of the product asks that service for a credential when it needs one; none of them keeps a cloud secret of its own.

The choice of cipher is worth one sentence. GCM does two jobs at once: it keeps the credential unreadable without the key, and it makes tampering detectable, so nobody can quietly alter the stored value. It is the current standard for this, and ISO 27001 and SOC 2 Type II auditors accept it.

2. One customer’s credentials cannot reach another

Every organisation’s credentials live in their own space. Nothing in the code can read, decrypt or use organisation A’s credential while acting for organisation B. Two separate mechanisms enforce that.

• In the database. Every credential belongs to exactly one cloud account, and every cloud account belongs to exactly one organisation. ZopNight looks the account up within your organisation before it fetches the credential.
• In the service. The gateway works out which organisation the caller belongs to before the request goes anywhere, so a query that crosses organisations cannot be formed.

Software serving many customers from one system has well-known ways of leaking data between them: a query that forgets to filter, an ID somebody can guess and increment, a cache shared by mistake. Each of those is closed here deliberately.

3. You can replace a credential without breaking anything

Customers can rotate a credential, or switch to a different connection method, at any time, without deleting the account. The rotation flow:

1. Customer creates or updates the IAM role / service account / SPN in their cloud
2. Customer opens the account and clicks Update credentials (Cloud Accounts UI)
3. The new credential is checked live against the cloud provider
4. It must resolve to the SAME cloud account; if not, nothing changes
5. If the check passes, the account's single vault entry is re-keyed in place
6. Cached provider tokens are cleared and discovery re-runs on the new credential

There is no overlap period and no second copy: the old credential is replaced, not kept. Resources, groups, recommendations, cost history and schedules all stay attached to the account, because they hang off the cloud account’s own ID rather than off the credential. A credential that points at a different account is refused, so a rotation can never quietly repoint an account somewhere else.

4. You can cut it off at the source

There is no “revoke” button inside ZopNight, because the real off switch lives in your cloud. To stop ZopNight using a credential, revoke or delete it where it was issued: the IAM role or its trust policy, the service account key, the client secret. Anything that tries to use it afterwards fails, and fails visibly rather than quietly reporting a smaller estate: ZopNight raises a credential alert, and when the cloud says outright that it no longer recognises the credential, the permission drawer reports that the account’s credentials are “invalid, revoked, or expired”.

You can also remove the cloud account in ZopNight. That deletes ZopNight’s stored copy of the credential from the vault, but it does not touch the role or key in your cloud. If you think a credential has got out, do both, and do the cloud side first.

If you kept the account in ZopNight, get going again by creating a new credential in the cloud and using Update credentials on that account. The check confirms it resolves to the same cloud account, and everything attached to the account comes back into use.

What the customer sees

The vault model is mostly invisible. The Cloud Accounts page shows:

• Account name, provider, and region
• Connection status
• Last successful sync timestamp
• An “Update credentials” action
• A “Remove” action that disconnects the account
• A “View Permissions” drawer (covered in L4)

What you never see is the credential itself. You cannot export it, and you cannot read it back after you submit it. If you lose your copy, your cloud provider is the only place to get another. ZopNight can confirm the credential works; it has no way to show it to you.

What ZopNight’s own engineers cannot do

They cannot read it either. The key that decrypts the vault is not reachable from the tools engineers use.

When a production problem genuinely needs credential access, there is a written emergency procedure that requires more than one person to approve, and every use of it is recorded in the security audit trail. That record is part of what SOC 2 evidence consists of.

2. Demo

The credential lifecycle in one timeline:

T+0       Customer creates IAM role in AWS Console
T+1 min   Customer pastes the role ARN into ZopNight Cloud Accounts page
T+1 min   ZopNight calls AWS STS AssumeRoleWithWebIdentity to validate
T+1 min   STS returns temporary credentials: validation passes
T+2 min   The role configuration is encrypted (AES-256-GCM) and stored
T+2 min   Discovery starts straight away on the new account
T+5 min   Customer sees the account marked Active in the UI
T+5 min   View Permissions fills in with each permission's status
T+6 hr    Discovery runs again, and every 6 hours after that
T+91 day  Customer rotates: Update credentials, re-keyed in place

Five minutes to active, with discovery already running. After that it repeats every 6 hours. Rotation is an in-place re-key that keeps everything attached to the account.

3. Hands-on (5 min)

This hands-on is a security-review walkthrough rather than a code task. Open ZopNight Cloud Accounts (or look at the Cloud Accounts page in a screenshot).

1. Click any connected account.
2. Confirm you cannot see the underlying credential value (only an
   identifier: role ARN, service account email, app ID).
3. Note the "Update credentials" and "Remove" actions.
4. Open the "View Permissions" drawer (covered fully in L4).
5. Check the "Last sync" timestamp. Should be within the last 6 hours.

If any element is missing or behaves unexpectedly, escalate. The
vault model has specific guarantees and any deviation is a bug.

4. Knowledge check

Q1

A Security team asks: “What happens to a credential after rotation?” Most accurate answer:

A. It stays valid for 24 hours so running jobs can finish, then it is deleted
B. It is archived in the vault so it can be restored if the account is reconnected
C. The new one is checked against the same account, then replaces it in place
D. Both are kept, and ZopNight picks whichever one works on each call

Q2

A Security team asks: “Can a ZopNight engineer decrypt our credential to help debug?” Most accurate answer:

A. Yes, on request
B. No
C. Only for premium customers
D. Yes, after written consent

Q3

A team suspects the secret behind one Azure cloud account has leaked. The right first move is:

A. Delete or rotate the secret in Azure, then use Update credentials in ZopNight
B. Click Remove in ZopNight; that also disables the secret inside Azure
C. File a support ticket asking ZopNight to revoke it from the vault
D. Wait for the next discovery sync to flag the secret as compromised

5. Apply

To audit the vault model on your own deployment:

• Cloud Accounts page: confirm credential values are not exposed
• Audit Logs page; filter to credential-related events to see credential updates, account removals, and permission changes
• Security review documentation: request the SOC 2 Type II report + ISO 27001:2022 certificate from ZopNight Trust Center

Related lessons

• L2: AWS IAM policy (next)
• L4: Permission Visibility
• T4.M4.3: Audit logging

Glossary terms touched

Credential rotation · Break-glass procedure