Cloud Networking and Identity

Introduction

In the cloud you do not plug in cables. You define networks and permissions in software. Two skills matter most: building networks that expose only what must be public, and controlling exactly who and what can access each resource. Mistakes in either are a leading cause of cloud breaches.

Virtual networks

A virtual private cloud (VPC), called a virtual network on some providers, is your own isolated network inside the provider's data centres. You choose its private IP range, using the private address ranges from the networking course.

Inside it you create subnets, smaller slices of the range, usually spread across several availability zones, which are separate data centres in the same region.

• A public subnet has a route to the internet. Web servers or load balancers can live here.
• A private subnet has no direct route from the internet. Databases and internal services live here.

Private resources that need to reach out, for example to download updates, use a NAT gateway, which allows outbound connections but blocks inbound ones.

Firewalls: security groups

A security group is a virtual firewall attached to a resource. Rules say what traffic is allowed in and out, and everything else is denied.

A sensible three-tier design:

1. Load balancer: allow HTTPS (port 443) from anywhere.
2. App servers: allow traffic only from the load balancer.
3. Database: allow traffic only from the app servers, on the database port.

Internet -> Load balancer (443 from anywhere)
         -> App servers   (only from the load balancer)
         -> Database      (only from the app servers)

Nobody on the internet can reach the database, even if it has a weakness.

Identity and access management (IAM)

IAM answers: who (or what) can do what on which resources.

• Users and groups for people
• Roles for applications and services, which receive temporary credentials automatically, so no long-lived keys are stored in code
• Policies are documents that list allowed or denied actions on resources

Example idea of a policy, in plain words: "This role may read objects in the bucket named reports, and nothing else."

Principles

• Least privilege: grant only the permissions needed for the job, and no more. Start narrow and add as required.
• No shared accounts, and never use the all-powerful root or owner account for daily work. Lock it away with multi-factor authentication.
• Multi-factor authentication for all human users.
• Prefer roles and temporary credentials over access keys. If you must use keys, rotate them.
• Review permissions regularly and remove what is unused.
• Separate environments, such as development and production, into different accounts or projects.

Common mistakes

• A storage bucket made public by accident
• A security group open to the whole internet (0.0.0.0/0) on SSH or a database port
• Access keys committed to a public repository
• Admin permissions given to everything "to make it work"

Try it yourself

Draw the network for a website with a database: list the subnets, which are public, and the security group rules for each tier. Then write the permissions a backup job would need, following least privilege.

Summary

• A VPC holds public and private subnets, and security groups allow only the traffic you list.
• Keep databases and internal services private, behind the application tier.
• IAM uses roles, policies, MFA and least privilege to control access, and avoids long-lived keys.