Turn STAC Transaction API endpoints on again

[j08lue]

We disabled the STAC API Transaction extension because we currently did not have a mechanism for authorization.

What are the steps for turning it back on? Do we need to wait for the API gateway (Tyk) setup to be ready, so we can secure those endpoints with Tyk? Or can we set up some simple intermediate auth mechanism?

Related ticket:

• Implementing Transaction API and Auth developmentseed/eoapi-k8s#33

Acceptance criteria

• The eoAPI deployment has working STAC Transaction endpoints that are secured with some (basic) form of auth

[pantierra]

It might be related to stac-utils/stac-fastapi-pgstac#166

[pantierra]

Is there already a ticket for the Tyk configuration to protect these endpoints?

In the meantime I could configure the ingress controller to protect the transactions endpoint with some BasicAuth. What do you think?

[j08lue]

We had this placeholder ticket last quarter:

• ​​Integration of Authentication & Authorization Mechanism for CRUD API with IAM (API Gateway) #2301 - Q2 data-access#81

We probably need a fresh plan for it from @jankovicgd.

Any interim simple protection of the Transaction API endpoints that we can remove later when the API Gateway is ready would be welcome.

We currently do not have our own runtimes in eoapi-k8s. I am not convinced we need them, longer-term. Our needs should not really deviate from what the runtimes included with the individual libraries provide.

[pantierra]

I’ve looked into this further, and it turns out that adding basic authentication is more complex than initially anticipated. The STAC API Transaction Extension uses HTTP methods like POST, PUT, and DELETE, and HTTP method-based routing is only supported if we use Traefik as the ingress controller, rather than Nginx.

After discussing with @alukach (🙏), the following approach seems to be the most recommended and should provide a robust, extensible solution for the EOEPCA project—eliminating the need for future changes:

• Build a custom stac-fastapi runtime for EOEPCA that integrates eoapi-auth-utils and leverages EOEPCA’s Keycloak for authentication.

The main tradeoff here is that we’ll need to set up a pipeline for building and deploying this custom runtime. However, this approach offers greater flexibility and scalability, allowing us to easily add additional functionality as needed in the future.

[j08lue]

Build a custom stac-fastapi runtime for EOEPCA

If it was only for auth, I would prefer that we stick to the default stac-fastapi-pgstac image and solve auth via ingress. But we will also need things like metrics (probably via OpenTelemetry), multidimensional dataset (Xarray) support, etc. and the default runtimes do not include these, so let us take the step now to set up our own runtimes.

Let us time-box this. One sprint and the new runtimes are up and include eoapi-auth-utils?

[jankovicgd]

I have published a chart where the control is implemented on database user level, taking advantage of a read user and ingest user that exist in pgstac by default. Then each of the users is connected to a different k8s deployment which is connected to a different k8s service and in the end a different k8s ingress. https://gitlab.eox.at/vs/stacapi-helm/

The idea with this approach is that there is a stac-read.example.com endpoint where read clients can be attached and whenever any write is attempted it fails at the database level, and a stac-ingest.example.com endpoint where every operation is protected by basic auth but here the read/write clients could be attached.

There are some drawbacks to this approach and may not be a good fit with the system.

• if a more finegrained access is needed this doesn't work
• ensuring clients are properly routed
• increased infrastructure
• database bottleneck
• monitoring 2 deployments
• updates of 2 deployments

Chart repo: https://charts-public.hub.eox.at/api/charts/stacapi

[jankovicgd]

My bad, completely missed the transaction extension. Back to the drawing board I guess

[pantierra]

This is an interesting approach, @jankovicgd! Thanks for sharing! For EOEPCA, I saw Basic Auth as a temporary solution, with the intention of eventually integrating it into a more robust authentication system. By leveraging eoapi-auth-utils in conjunction with EOEPCA's Keycloak, we're already taking a step toward a proper solution for the project