liveBook · Manning

Authorization decision

As explained in Google Anthos in Action

Authorization is the process of determining which actions or resources an authenticated actor is permitted to access.

An authorization decision determines whether an authenticated user, service, or workload may perform an action or access a resource. In distributed systems, the decision is enforced across service boundaries, cluster layers, and cloud projects rather than at a single endpoint. section 4.3.3 section 2.3.2

Authorization decisions appear in several operational layers:

  • Service meshes apply identity-based authorization to service-to-service communication and expose policy controls for access control, quotas, and rate limits. section 4.3
  • Clusters use role-based access control so existing permissions govern both direct connectivity and requests passing through a proxy. section 2.3.2
  • Cloud access adds another decision: a user must be permitted to view the attached Google Cloud project before using Connect, even when cluster permissions allow access. section 2.3.2
  • Layered validation rejects requests that skip an authentication or authorization stage, preventing an invalid request from proceeding to the next layer. section 2.3.2

A proxied cluster request

A user connects to a cluster through Anthos Connect. The request carries the user’s credentials, is authenticated at each stage, and must satisfy both cluster RBAC and permission to view the associated Google Cloud project. Failure at any layer rejects the request. section 2.3.2

Figure 4.5 Istio authorization architecture
04-05

Use the authorization architecture to trace how identities, policies, and enforcement components participate in a service-mesh authorization decision. section 4.3.3

How Google Anthos in Action covers it

How deep it goes
Traces layered identity and permission checks but does not specify detailed authorization policy syntax.
Examples
Uses Istio service authorization, Anthos Connect requests, cluster RBAC, and Google Cloud project visibility checks.
What it assumes
Assumes authenticated identities and basic familiarity with cluster RBAC, cloud projects, proxies, and service communication.
What you can do after
Evaluate/understand why a distributed request is allowed or rejected at service, cluster, proxy, and cloud-permission layers.
How it connects
Connects authentication, RBAC, IAM, service mesh, zero-trust security, and policy enforcement.

Also explained in

Compare how 7 books explain authorization decision →

Related concepts

This explainer was generated by Manning's knowledge graph from the text of Google Anthos in Action. The section links point to the parts of the book it draws on.