include /cog endpoints in titiler-pgstac by default

[hrodmn]

This issue may belong in titiler-pgstac, but one thing that would make the default eoapi-cdk deployment even better would be to include the /cog endpoints from titiler. @jjfrench is working on consolidating our titiler deployments over in MAAP and one thing that is preventing us from running everything on a single titiler-pgstac deployment is the /cog endpoints which are available in an old titiler deployment but not in the eoapi deployment. It can be useful to be able to use the /cog endpoints to inspect data before it is cataloged in a STAC item. Maybe it would be better described by a set of /external endpoints to use for data that is not in the STAC yet. I'm not sure but I think there has been a similar discussion in VEDA cc @wildintellect.

It would be pretty simple to add to the handler.py in this repo or in titiler.pgstac.main.app. A user could customize eoapi to add these endpoints but it might also make sense to include that set of endpoints by default.

[vincentsarago]

IMO, no custom handler should live in eoapi-cdk! That's said, we have three choice:

• add to titiler-pgstac: this would have a set of /cog prefixed endpoint which could potentially be open to all dataset and represent a kinda security issue (you don't want people using your titiler endpoints for their dataset)
• add a new optional service just with titiler app (from titiler.application module), not linked to any pgstac stuff and having it's own url. The issue is then you can't have both titiler and titiler-pgstac endpoint using the same url, like raster.eoapi.dev.
• don't change anything and continue with custom runtimes

[wildintellect]

So the default is the Tiler works with any bucket, but we restrict it to only the STAC records, so some control over that buckets is possible? Should default config recommend an Allow list that would apply to the COG endpoint to prevent usage outside of expected buckets, in titiler-pgstac?

@hrodmn @jjfrench which solution do you think makes the most sense?

[hrodmn]

Thanks for your suggestions, @vincentsarago! If you are open to it my preference would be to add an option in titiler-pgstac for users to enable the basic TilerFactory endpoints (commonly prefixed with /cog), then users could use the apiEnv to turn it on in eoapi-cdk.

I think the discussion about security in the MAAP context belongs in https://github.com/NASA-IMPACT/active-maap-sprint/issues/988 so I'll take that discussion over there, but it is already possible to specify the S3 buckets that the titiler-pgstac Lambda has access to using the buckets parameter:

eoapi-cdk/lib/titiler-pgstac-api/index.ts

Line 130 in 7536c55

readonly buckets?: string[];

The default behavior is to allow access to NO buckets but it is possible to provide a wildcard and enable ALL buckets, which is what I have done in the past. For MAAP we specify a single bucket for the titiler-pgstac instance:
https://github.com/MAAP-Project/maap-eoapi/blob/main/titiler_buckets.yaml#L2

I'm not sure that prevents someone from requesting tiles for a dataset at an arbitrary URL, though, so to prevent access to all files on the web we would need to make sure the Lambda didn't have internet access.