Protect eoAPI's STAC API Transaction Extension endpoints

[pantierra]

Related to issues #90 and #12

The STAC API, part of EOEPCA's eoAPI, requires protection for its CRUD operation endpoints as defined by the STAC API Transaction Extension. Authentication for these endpoints will be managed through the project's Keycloak instance.

We are currently evaluating several approaches for securing these endpoints:

• Application runtime integration: One approach is to integrate endpoint protection directly within the application runtime by leveraging stac-fastapi-pgstac alongside eoapi-auth-utils. This solution offers a straightforward way to implement authentication within the STAC API component itself.

• Dedicated auth proxy: Another option is to deploy the lightweight proxy stac-auth-proxy between the internal STAC API endpoints and the ingress. This proxy would handle authentication for the designated endpoints, providing a clean separation between the API logic and the authentication layer. Additionally, it offers flexibility, as it integrates seamlessly within the same ecosystem as the application.

• Kubernetes ingress proxy: Leveraging Kubernetes Ingress for authentication is another potential solution. While this can offer a centralized mechanism for securing the API, it has limitations that make it more complicated compared to the other options. Kubernetes Ingress is not primarily designed for handling authentication, and its configuration can become complex when enforcing fine-grained access control for specific endpoints.

• API Gateway: Finally, we are considering managing authentication and protection for all STAC API endpoints through the project’s apisix API Gateway. This approach would centralize access control, but it may introduce additional limitations in terms of functionality and customization.

I currently favor the second approach using a proxy. This would allow us to continue running eoAPI without modifying the packaged runtime, while also providing greater flexibility.

Acceptance criteria

• Decided on an approach and documented in this ticket
• Validated and implemented the approach
• Added documentation to our RTD

[j08lue]

Decision from meeting today:

We will start by trying to solve this simple case using the API Gateway (APISIX + KeyCloak or OPA) and configure two routes on the same application to behave differently:

GET /stac/collection (open)
POST /stac/collection (protected)

There are indications that HTTP method-based auth should be possible with APISIX https://apisix.apache.org/docs/ingress-controller/concepts/apisix_route/#advanced-routing

This will follow the example of the Workspace API, which is currently under development.

[pantierra]

Linking related issues about authentication and API gateway:

• Definition of users and teams: IAM <-> Workspace integration for initial workspace provisioning workspace#34 This is a prerequisite to protect the endpoints.
• Endpoint protection: IAM <-> Workspace integration for scoped Workspace-API access workspace#37

For reference, these are the endpoints and their http methods we want to protect:

• https://eoapi.develop.eoepca.org/stac/collections", POST
• https://eoapi.develop.eoepca.org/stac/collections/{collection_id}, PUT, PATCH, DELETE
• https://eoapi.develop.eoepca.org/stac/collections/{collection_id}/items, POST
• https://eoapi.develop.eoepca.org/stac/collections/{collection_id}/items/{item_id}, PUT, PATCH, DELETE
• https://eoapi.develop.eoepca.org/stac/collections/{collection_id}/bulk_items, POST

[j08lue]

from @achtsnits

from the workspace perspective there are currently two topics ongoing with the IAM BB:

• user<->groups in Keycloak (IAM <-> Workspace integration for initial workspace provisioning workspace#34): Establishing the concept of users and groups=team, auto-provisioning groups/memberships, and enforcing this on the WorkspaceUI endpoint so only group members can access the corresponding team's WorkspaceUI deployment. Discussed today: this concept can be applied to operator user setup as well (e.g., IaC/GitOps topic).
• restricting access to routes of WorkspaceAPI (IAM <-> Workspace integration for scoped Workspace-API access workspace#37): Limiting access to specific HTTP routes of the central WorkspaceAPI deployment.

Discussed today: exploring Keycloak policies based on HTTP methods for #101. Once done with the route, we will follow up with proper ingresses for STAC API Admin tools/endpoints based on HTTP methods (see https://eoepca.slack.com/archives/C078J079YLR/p1733231324225879 above)

[j08lue]

Plan from here:

1. IAM team implements a proof of concept to distinguish between the GET and POST methods on https://eoapi.develop.eoepca.org/stac/collections, where the former is open and the latter is protected via KeyCloak (group membership in an admin group or so) Implement ingress control distinguishing between GET and POST to eoapi/stac/collections #102
2. BB updates ingress configuration to connect <- need instructions from IAM team
3. We'll plan implementation of the auth flow in STAC Manager and either implement one, deploy it against an open copy of the service, or omit it from the 2.0.0-beta.2 release.

[j08lue]

See update here:

• Implement ingress control distinguishing between GET and POST to eoapi/stac/collections #102 (comment)