- Region equals a geograpic location
- Zones divide regions into (physically) independent isolated sub parts
- Some resources are
- accessible only within one zone (e.g. VMs)
- can be shared across zones (e.g. Subnets, static external IP addresses)
- can be shared across regions (e.g. images, VPC)
- it’s simply a way to organize resources from a billing and permissions perspective
- each project has its own VPC network(s) isolated from other projects in GCP
- Cloud IAM is the GCP offering that manages
- who (identity)
- has what access (role)
- to which resources
- identities (members) can come from multiple pools:
- Google account
- Service account
- Google group
- G Suite domain
- Cloud Identity domain
When authenticated member makes a request in GCP, Cloud IAM makes an authorization decision about whether the member is allowed to perform the operation on a resource
-
Resources you can grant members access to GCP resources, e.g. projects, GCE instances, cloud storage buckets
-
Permissions permissions determine what operations are allowed on a resource
- permissions are represented in the form of ..
, e.g.pubsub.subscriptions.consume` - permissions are not directly assigned to users but to roles
- permissions are represented in the form of ..
-
Roles are collections of permissions
- you cannot assign permissions directly to users, but use roles to assign permissions
- when granting a role to a user, all permissions of the role are granted to the user
- 3 kinds of roles in GCP
- primitive: owner, editor, viewer
- predefined roles
- custom roles
-
IAM Policy used to grant roles to users
- defines who has what type of access
- a policy is attached to a resource
- A service account corresponds to a technical user (assigned to an application or VM).
- the service account is the identity of the service
- the service account's permissions control which resources the service can access
- a service account is associated with a key pair used for service-to-service authentication
- A Virtual Private Cloud (VPC) is a global private isolated virtual network partition that provides managed networking functionality for your Google Cloud Platform (GCP) resources.
- VPC is globally spanning
- instances within VPC have private IP addresses and can communicate privately with each other
- each network has its own subnets, routes, firewall, internal DNS...
- is associated to a GCP Project and contains (amongst others)
- VPC Network
- Subnets
- Routes
- Firewall
- Internal DNS
- you can have up to 5 networks per project
- each VM inside a VPC has an internal IP and typically an external IP
- Internal IPs are allocated to instances from the subnet’s IP range via DHCP. This means the IPs are ephemeral and will be released if the instance is deleted.
- External IPs are also assigned via DHCP from some Google-provided pool. These IPs are mapped to the internal IPs of the VM instances for you. You can reserve static IP addresses if needed.
- all networks have routes in order to communicate with each other
- the default network has a default route to the internet and individual routes to each subnet
- Routes are considered a “network resource” and cannot be shared between projects or networks
- Routes could apply to multiple instances or single instances depending on the tags used in the route statement
- If an instance tag is used, the route applies to that instance, and if an instance tag is not used, then the route applies to all instances in that network
- Individual read-only route tables are created for each VM instance based off of the parent route table
- Even though there are no “routers” in the software-defined network, you can still think of each VM instance as connected to some core router, with all traffic passing through it based on the perspective of each node’s individual route table.
- Routing decisions apply to traffic egressing a VM. The most specific route in the table will match. Traffic must match a route and firewall rule in order for it to pass.
- each network has its own distributed firewall
- allows traffic into or out of the network
- has explicit deny policy
- all allow traffic has to be explicitly allowed
- you cannot create deny rules
- firewall rules can match IP addresses or tags
- Tags are user-defined strings that help organize firewall policies for standards-based policy approach.
- For example, you could have a tag called web-server, and have a firewall policy that says any VM with the tag web-server should have ports HTTP, HTTPS, and SSH opened.
- Firewall rules are at the network resource level and are not shared between projects are other networks.
- When a VM instance is created, DNS entries are automatically created resolving to a formatted hostname
FQDN = [hostname].c.[project-id].internal- Resolution of this name is handled by an internal metadata server that acts as a DNS resolver (169.254.169.254), provided as a part of Google Compute Engine (GCE)
- will answer both internal queries and external DNS queries using Google’s public DNS servers
- use API call to create a meta pipeline in Cloud Build
- meta pipelines creates 2 more pipeline in Cloud Build
- a pipeline that runs Terraform to provision GCP infrastructure
- a pipeline that builds containers which are then deployed into the previously provisioned infrastructure
- Terraform pipeline and container pipeline is triggered via changes in source code repository
- how to connect from Cloud Build to GitHub
- how can we automate creation and propagation of auth tokens
- how do we give resource permissions to Cloud Build jobs
- how can we create a cloud build job from CLI - or even better: with a Terraform module
- use
gcloud builds submit - how can we create a cloud build job from within another cloud build job
- see
gcloud-builder
- see
- how can we run a Terraform plan from within a Cloud Build job
- https://cloud.google.com/cloud-build/docs/api/reference/rest/v1/projects.builds/create
- https://github.com/GoogleCloudPlatform/cloud-builders-community/tree/master/terraform
- Management access to machines (ssh) via Cloud AIP
- GCP does not offer any managed VMS, OS is fully managed by customer
- Kubernetes Engine offers in-place update of K8S clusters, either automatically or with a defined time-window
- if cluster has multiple nodes, zero-downtime is achieved
- app engine as PaaS offering (== PCF)
- pipelines with Cloud Build to bootstrap infrastructure / environment
- Spinnaker for Continuous Deployment / Delivery
- Stackdriver for monitoring / debugging
- Istio for service mesh
- Types of accounts
- private accounts (google accounts) - don't use them in production projects
- organization accounts (administrator managed)
- two consoles for user management
- Cloud Identity Admin console - for managing authorization
- Cloud console IAM - for managing permissions
- Organization hierarchie: organization --> folder --> projects --> resources
- Permissions can be organized via folders and groups
- User accounts (humans) and service accounts (machines) can be assigned to roles
- service account is a resource himself
- in order to be able to use a service account, you need to have permission on the role
- quotas protect you from unexpected high costs
- network concepts
- project is the container / wrapper around everything (related to networking)
- within a project I can create a (globally spanning) VPC (network)
- network can span regions, a region contains zones
- within a network, one can create a subnet that can span multiple zones within the same region
- when creating a new project a new default network is created
- also, in each region a new default subnet is created
- Billing is associated with a Billing Account that is independent of organization and projects
- a billing account is assigned to one or more project(s)