Platform services in Google Cloud act in the context of a service account. While these default service identities are mostly generated automatically, it is not always deterministic when they are created. Some are created when the API is enabled, others will only be created on first use of the API. This makes it hard for managing IAM permissions for these identities - especially when employing infrastructure as code like Terraform.

It could happen. Total mahem. An administrative pricipal for a project was accidentally leaked. An attacker has taken you projects hostage. You need to recover and fast. Restoring project access is the least of your worries your concern is to restore services. Luckily you have all workloads protected with snapshots! All deleted by the attacker! This is an exaggerated and hypothetical scenario but I have seen similar things happening. In this article I’m exploring an approach to protect against such a scenario.

Identity-Aware Proxy (IAP) is a powerful tool in the tool chain of Google Cloud administrators and users. It can be used to control access to cloud-based and on-premises applications and VMs running on Google Cloud.

IAP adds *common *authentication and authorization infrastructure based on Cloud IAM to connections without the need for a change to program or protocol logic. By removing the need to expose connection endpoints to the public internet, IAP works from all networks without the need for a VPN connection.

If you have not been working with Management Groups to manage Azure at scale, I recommend to review the documentation. You should also take a look at the Microsoft Cloud Adoption Framework (which was just recently updated).

When you start using Management Groups you might want to change the display name of the root management group or do other changes to the hierarchy. To get started you need to have access to the root management group. If you have global administrator permissions, follow the documentation (especially this) on how to set that up.