Google Cloud / Advanced: Governance, Reliability, and Architecture / Lesson 13
Layered Security and Governance
Assign a distinct purpose, owner, and verification method to identity, organization policy, network boundaries, secrets, encryption, and audit controls.
On this page
Lesson goals
- Distinguish IAM, organization constraints, and service perimeters.
- Design secret and encryption-key lifecycles.
- Review control evidence without probing an environment.
Several controls can apply to the same request
IAM grants and denies authority, organization policies constrain supported resource behavior, and network policy controls traffic paths. VPC Service Controls adds service-perimeter protections for supported services and data-access scenarios; it is not an ordinary packet firewall or a replacement for IAM. A design should name which threat and resource each layer addresses.
A stronger-looking flag is not a universal security result. A perimeter can have service limitations and ingress/egress rules; an organization constraint can have hierarchy and exception semantics. Review current support, dry-run capabilities where appropriate, and authorized change processes before enforcement. This lesson performs no policy change or security scan.
Secret storage is only part of credential management
Secret Manager provides versioned secret storage and access controls under its contract. Applications still need an identity, least-privilege access, safe delivery, rotation handling, and a policy for cached or disabled versions. A rotation schedule or notification is not proof that a downstream password and every consumer have changed successfully.
Keep secret payloads out of source, images, logs, Terraform outputs, and public examples. A reference to a version can be useful metadata without being the secret itself. Choose explicit versus moving version references according to rollout and rollback needs, and review who may add, access, disable, or destroy versions.
records = [{"name": "database-credential", "owner": "data-team", "version_reference": "version-3"}, {"name": "api-credential", "owner": "service-team", "version_reference": "version-2"}]
assert all(record["owner"] and record["version_reference"] for record in records)
assert all("payload" not in record for record in records)
print(f"synthetic_references={len(records)} payload_fields=0")
synthetic_references=2 payload_fields=0
The records contain owners and version references only; no secret value is read or verified.
Encryption-key control also creates an availability dependency
Cloud KMS and service-specific customer-managed encryption-key support let organizations control selected key relationships. Encryption at rest, transport encryption, and application authorization solve different problems. Possessing a key-management role does not automatically authorize all data reads, and a data role does not imply authority to destroy the key.
Key location, service-agent access, rotation, disabling, destruction, and recovery requirements must match the data service. Losing access to a required key can affect live data and backups. Do not treat key deletion as routine cleanup or assume key rotation re-encrypts every historical copy under identical semantics. Read the exact service integration.
Evidence should identify a gap, not invent assurance
The second offline example lists required review evidence and subtracts the recorded items. The missing restore-key-access item signals an unresolved dependency in a synthetic design. It does not inspect keys, access policies, or backups. A complete operational record should link to controlled evidence with time, scope, owner, and an approved test or review method.
Audit logs and Security Command Center findings can support investigation according to enabled services and tiers. A finding is evidence to triage, not proof that every risk is detected or that remediation occurred. Establish ownership, severity context, exceptions, and closure evidence without exposing sensitive contents.
required = {"runtime-identity", "secret-owner", "restore-key-access"}
recorded = {"runtime-identity", "secret-owner"}
print("missing", ",".join(sorted(required - recorded)))
missing restore-key-access
The local set comparison lacks restore-key-access evidence and evaluates no real control.
Governance needs exceptions and incident ownership
Define who approves policy exceptions, how long they last, what evidence supports them, and how they are removed. Keep emergency access usable under a controlled audited process rather than distributing shared credentials. Separate routine runtime identities from administrators and recovery operators while ensuring recovery remains feasible.
Review changes across identity, data classification, retention, keys, networks, and logs. A secure design is a maintained set of responsibilities and tests, not a single product purchase or compliance label. All executable examples here operate on invented local metadata; real security assessment and enforcement require separately authorized work.
Common errors and fixes
A service perimeter is treated as a packet firewall.
- Why it happens
- Supported API/data boundaries were confused with network filtering.
- How to fix it
- Review the exact VPC Service Controls scope and keep IAM/network controls separate.
- Prevent it next time
- Map each control to its threat and resource.
A rotation notification is called completed rotation.
- Why it happens
- A trigger was confused with consumer migration.
- How to fix it
- Define and verify the downstream rotation workflow.
- Prevent it next time
- Record version, consumer, and rollback evidence.
A key lifecycle change breaks recovery.
- Why it happens
- Backup and service-agent key dependencies were omitted.
- How to fix it
- Review retention and restore access before any authorized key change.
- Prevent it next time
- Include keys in the dependency and recovery map.
Check your understanding
1. A team adopts CMEK and claims that IAM review is no longer needed. Explain the mistake.
Show worked solution
Key control and data authorization govern different relationships. The service still needs correct runtime and service-agent permissions, and callers still need appropriate resource access. Key administration can also create availability and recovery risks. Review the exact product integration, separation of duties, key location/lifecycle, and backup access rather than treating encryption as a replacement for authorization.
2. What must accompany a policy exception so it remains reviewable?
Show worked solution
Name the business need, exact resource and principal scope, approving owner, expiry/removal trigger, compensating controls, evidence, and incident implications. An exception should not silently become a permanent broad grant. Keep the approval record separate from proof that the policy was actually enforced; both matter, and an offline metadata check establishes neither by itself.
Key takeaways
- Identity, policy, network, secrets, and keys have distinct purposes.
- Protection can create availability and recovery dependencies that need ownership.
- Offline evidence lists are not security assessments or enforcement tests.