Keystone: identity and access across platform and cloud

A platform identity and a cloud identity do not automatically grant the same access. Applications, service accounts and administrators need a consistent way to express permissions for platform resources and the associated cloud services.

The inspected twelve-slide presentation frames Keystone around unified identity management, centralized authorization and GCP resource access. It supports this architectural scope; it does not establish a start date, a population served or measured security outcomes.

We developed Keystone in 2023–2024 with Keycloak and Open Policy Agent (OPA), integrating Keycloak with Google Cloud Workforce Identity Federation and IAM. The twelve-slide presentation also describes OpenID Connect authentication, a FastAPI gateway and a Python client for gateway interactions.

Workforce federation lets externally authenticated users access Google Cloud under IAM permissions. It is user identity federation, distinct from workload identity federation for software workloads. OPA supplies a policy-decision responsibility for application access; gateway/platform enforcement and Google IAM resource permissions are separate scopes.

The diagrams combine the confirmed implemented integration with Google’s documented federation model. The product flow exchanges an external credential through Security Token Service for short-lived access; the particular provider claims, token caches and revocation behavior of this deployment have not been inspected.

Authentication answers who is requesting access. Authorization answers whether that identity can perform an operation on a resource. The presentation connects both, while naming policy enforcement for buckets and BigQuery and access rules for FAO Maps.

The presentation describes RBAC and ReBAC for platform users and service accounts. The implemented stack also uses OPA. Policy decisions and enforcement should be distinguished: naming OPA does not mean it replaces Google IAM or prove particular Rego rules, decision caching or resource attribute mappings.

A retrospective alternative is to let each application maintain its own identity-to-cloud mapping. That reduces central dependencies, but multiplies permission administration and makes alignment harder. I would evaluate the central gateway against that administrative cost, while measuring its own availability and policy-propagation requirements.

We implemented Keystone using Keycloak and OPA alongside GCP IAM, with Workforce Identity Pool integration, in 2023–2024. The architecture presentation documents the FastAPI gateway, Python client, authentication and role/group/policy administration, including an authentication demo section.

This is FAO institutional work delivered with colleagues. The public case describes the evidenced components and my contribution, without asserting user counts, token-lifetime guarantees, particular deployment infrastructure or independent security certification.

An identity integration is only as clear as the enforcement boundaries around it. A design review should trace user identity, service-account identity, the policy decision and the final resource operation separately.

The next evidence I would request for an operational review is a resource-specific access trace, including denied access, token revocation and service failure. These are review criteria, not a statement that a particular caching or recovery mechanism was implemented.