Identity & Permissions
Identity & Permissions
Our cloud application is now running smoothly. Developers are deploying new features. Database administrators manage data. Network engineers configure security. Operations teams monitor the infrastructure. But here's the problem. Should every engineer have permission to do everything? Should an intern be able to delete a production database? Should a web application have permission to modify every resource in the cloud? One wrong action... ... could bring down the entire system. The engineering problem became clear. How do we give the right access to the right people and the right applications? The engineering concept that solved this problem is Identity and Access Management (IAM). Instead of giving everyone full control, permissions are granted based on roles and responsibilities. A developer may deploy applications but not delete databases. A database administrator can manage databases but not networking. An application receives only the permissions it needs to perform its job. This follows an important security principle: Least Privilege — give only the minimum access required. Amazon Web Services provides this through Identity and Access Management (IAM). Microsoft Azure provides Microsoft Entra ID (formerly Azure Active Directory) together with Azure Role-Based Access Control (Azure RBAC). Google Cloud provides Cloud Identity and Access Management (Cloud IAM). Different names. One engineering concept. Cloud security became about who can do what, not just who can log in. But another question soon emerged. Where should all these cloud resources actually live so that some are public and others remain private?