Lahiru Jayathilake created AIRAVATA-3978:
--------------------------------------------
Summary: Dynamic Access Policy Engine: Research & PoC
Key: AIRAVATA-3978
URL: https://issues.apache.org/jira/browse/AIRAVATA-3978
Project: Airavata
Issue Type: Task
Components: Custos Airavata Integration
Reporter: Lahiru Jayathilake
h3. Summary
Research, evaluate, and prototype a dynamic policy enforcement engine for
Custos that can make attribute-based access decisions across all Custos
services. This includes evaluating policy engines (AWS Cedar, OPA, Google
Zanzibar, and others), prototyping with the most promising candidates, and
demonstrating enforcement through real-world use cases relevant to research
computing.
h3. Problem
Research computing infrastructure increasingly needs to enforce dynamic access
restrictions based on who a user is and the context of their request. Some
real-world examples:
* A governance directive restricts access to certain compute resources for
users outside a specific geographic region
* A dataset is classified and only researchers from approved institutions with
active clearance should access it
* A compute partition is reserved for users with active allocations: no
allocation, no access
* During a security incident, an admin needs to instantly block a class of
users from accessing resources without disabling individual accounts one by one
Custos authenticates users (verifies who they are) through its identity
management layer. The next step is a general-purpose authorization layer that
other Custos components can call to answer: "Should this user be allowed to do
this action on this resource, right now?"
This enforcement layer needs to be invocable from multiple integration points
across the system. For example, Custos integrates with PAM modules on HPC login
nodes for SSH authentication. The policy engine would need to be queryable from
that PAM flow so that even at SSH login time, the system can check dynamic
policies (like geographic restrictions or allocation status) before granting
access. Similar enforcement points exist in the REST API layer, the SSH
certificate signer, and the allocation management service.
h3. Description
This project is a {*}research and prototyping task{*}. The student will survey
the policy engine landscape, evaluate candidates against Custos's requirements,
and build a working proof of concept. The goal is to give the Custos team a
clear recommendation backed by hands-on experience, not to build the production
integration.
# *Survey and evaluate policy engines* (deep-dive on top 3, survey the rest):
*Deep-dive candidates:*
* {*}AWS Cedar{*}: Attribute-based access control (ABAC) engine with a clean,
readable policy language. Designed for fine-grained authorization with formal
verification. Open source. Well-suited for conditions like "ALLOW if
user.affiliation IN approved_institutions AND user.region == 'US'".
* {*}Open Policy Agent (OPA) with Rego{*}: General-purpose policy engine. Very
mature and widely adopted. Rego is a powerful but complex query language. Can
model any authorization pattern but has a steeper learning curve.
* {*}Google Zanzibar / SpiceDB{*}: Relationship-based access control (ReBAC).
Models authorization as relationships: "user X has relation Y to resource Z".
Strong for modeling organizational hierarchies and resource sharing. SpiceDB is
the leading open-source implementation.
*Survey candidates* (evaluate at a high level for fit, don't prototype):
* {*}Cerbos{*}: Open source, ABAC-focused, simpler than OPA, designed for
microservices
* {*}OpenFGA{*}: Open source Zanzibar implementation by Auth0/Okta,
relationship-based with conditions support
For each engine, evaluate:
* Policy language expressiveness: can it naturally express the use cases below?
* Integration model: sidecar, library, or remote service? Latency
characteristics?
* Attribute handling: how does it consume external data (user attributes,
allocation status, geographic data)?
* Multi-tenancy: can different tenants (sites/gateways) define their own
policy sets?
* Audit trail: does it produce explainable decisions (which policies matched,
why allow/deny)?
* Operational maturity: community, documentation, production adoption
# *Prototype with 2-3 engines* against these use cases:
* {*}Geographic access restriction{*}: Evaluate a policy that restricts access
to a compute resource based on the user's institutional affiliation or
geographic region. Example: "DENY if user.country NOT IN ['US', 'CA']"
* {*}Allocation-gated access{*}: Check whether a user has an active,
non-depleted allocation on the requested resource before allowing access. This
requires the policy engine to query external state (the allocation service).
* {*}Emergency user blocking{*}: Model a scenario where an admin publishes a
"block list" policy that immediately denies access for a set of users or a
class of users (e.g., all users from a specific institution), without modifying
individual accounts.
* {*}Time-based access{*}: A resource is only available during certain hours
or a maintenance window blocks access temporarily.
For each prototype, demonstrate:
* Writing the policy in the engine's language
* Feeding user attributes and request context into the evaluation
* Getting an allow/deny decision with an explanation
* Measuring evaluation latency
# {*}Design the integration architecture{*}:
* How would the chosen engine be deployed alongside Custos services?
* How would existing Custos components (signer, allocation service, PAM module
on HPC nodes) call the policy decision point?
* How would policies be managed per-tenant (each site defines its own rules)?
* How would policy changes be deployed and tested safely (dry-run / simulation
mode)?
# *Deliver a recommendation report* covering:
* Comparison matrix of all evaluated engines
* Prototype results with code and performance measurements
* Recommended engine with rationale
* Proposed integration architecture for Custos
* Limitations and open questions
h3. Expected Deliverables
* Policy engine comparison report (Cedar, OPA, Zanzibar/SpiceDB, Cerbos,
OpenFGA) evaluated against Custos requirements
* Working prototypes with at least 2 engines demonstrating all four use cases
* Integration architecture proposal showing how the policy engine fits into
Custos (including PAM, signer, allocation service enforcement points)
* Recommendation report with rationale, prototype code, and performance
benchmarks
h3. Required Skills
* Go or Java (for building the prototype service and integration code)
* REST API design
* Understanding of authorization concepts (RBAC, ABAC, ReBAC), or willingness
to learn
* Comfort reading and writing policy languages (Cedar, Rego, etc.), or
willingness to learn
* Basic understanding of how SSH/PAM authentication works, or willingness to
learn
h3. Resources
* {*}Custos repository{*}:
[github.com/apache/airavata-custos|https://github.com/apache/airavata-custos]
* {*}Custos identity module{*}: identity/ directory for understanding the
current authentication layer (TokenAuthorizer, AuthClaim)
* {*}PAM integration{*}: deployment/account-provisioning/ shows how Custos
integrates with PAM modules on HPC login nodes via pam_oauth2_device for SSH
authentication
* {*}Signer service{*}: signer/ directory for the SSH certificate signing
service, one of the enforcement points
* {*}AWS Cedar{*}: [https://www.cedarpolicy.com/] and
[https://github.com/cedar-policy]
* {*}Open Policy Agent{*}: [https://www.openpolicyagent.org/] and
[https://play.openpolicyagent.org/]
* {*}Google Zanzibar paper{*}: [https://research.google/pubs/pub48190/]
* {*}SpiceDB{*}: [https://authzed.com/spicedb] and
[https://github.com/authzed/spicedb]
* {*}Cerbos{*}: [https://cerbos.dev/] and [https://github.com/cerbos/cerbos]
* {*}OpenFGA{*}: [https://openfga.dev/] and
[https://github.com/openfga/openfga]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
