Helm chart for stac-auth-proxy

[batpad]

First draft for a Helm Chart for stac-auth-proxy.

@emmanuelmathot I liberally used AI to help me write this code, and I think some of the stuff might be a bit much in terms of the configuration options.

Would be great to get just a bit of initial feedback here and then I can work on testing this and then adding the CI to publish the chart, etc.

cc @sunu for visibility

[emmanuelmathot]

Dont forget serviceaccountname placeholder int deployment as we need it to access secrets in general and on azure specifically

[emmanuelmathot]

@batpad I will give a deeper look on the whole chart tomorrow.

[batpad]

Dont forget serviceaccountname placeholder int deployment as we need it to access secrets in general and on azure specifically

@emmanuelmathot what sort of secrets would stac-auth-proxy need access to? Afaik, it should just need the openid-configuration URL, and so far I don't think any of the config parameters it needs need to be secret. I totally could be missing something.

[emmanuelmathot]

When utilizing RBAC resources, it's important to have the option to set the service account. For example, this is useful for pulling images from a secure hub when the keys are delegated to a specific service account. Best practices recommend always using a service account for security reasons. This approach does not necessarily complicate the chart.

[batpad]

@emmanuelmathot made a push adding a service account definition and some configurability in values - here I'm really not fully sure how this works, so please let me know if this is not what you had in mind. Thank you!

[emmanuelmathot]

that's perfect. Thank you @batpad

[batpad]

I've used the helm chart here to deploy a test instance to our Labs cluster: https://stac-auth-proxy-test.k8s.labs.ds.io/

I used the following values over-ride:

ingress:
  enabled: true
  host: stac-auth-proxy-test.k8s.labs.ds.io
  annotations:
    cert-manager.io/cluster-issuer: "onyx-onyx-stack-letsencrypt"
  tls:
    enabled: true

config:
  # upstreamUrl: "https://montandon-eoapi-stage.ifrc.org/stac/"
  upstreamUrl: "https://eoapi.ifrc-risk.k8s.labs.ds.io/stac"
  oidc:
    discoveryUrl: "https://goadmin.ifrc.org/o/.well-known/openid-configuration"

The deploy seems to be working and the startup logs look good. @alukach I'll need your help to properly test this (as well as some questions around working with the JWT tokens we intend to use).

@emmanuelmathot - this seems to successfully deploy - is there anything else you feel we should do before we can merge here? Else I'll feel okay merging once I've confirmed with @alukach that things work as expected.

[emmanuelmathot]

LGTM

[alukach]

So is this rendered in your terminal at time of deployment?

[batpad]

Yes, this is what renders when you do helm install / helm upgrade

[batpad]

@alukach I have changed the structure of the values being passed in as env vars based on our discussion and your suggestion.

I do much prefer this, so thank you. So now,

• env is an object in values where any key you add to env will be passed down as the same env var name to the container. The documentation then points to the README at the root for documentation on the env vars.
• the README, NOTES.txt, etc. should all be updated accordingly.

I've still left documentation for the possible env vars in the values.schema.yaml so we can specify types of the config values we know about. Am not sure though, maybe it's best to remove those and just leave in the required values. Will discuss quickly with @emmanuelmathot .

@emmanuelmathot let know if this change to just using env var literals in values instead of inventing a nested config structure makes sense - this commit mostly: 339132a

Am really not sure why I went with the nested config structure on the first pass, some misguided sense of something that I did not fully think through - thanks again @alukach, I do much prefer this way.

[alukach]

Looks good, should we merge?

[batpad]

Hmm .. tried rebasing and then testing running this on the labs cluster, and am getting errors in the logs that I'm not sure I can figure out @alukach -

kubectl logs stac-auth-proxy-test-759f64798b-splg9 -n batpad
INFO:     Will watch for changes in these directories: ['/app']
INFO:     Uvicorn running on http://0.0.0.0:8000 (Press CTRL+C to quit)
INFO:     Started reloader process [1] using StatReload
Process SpawnProcess-1:
Traceback (most recent call last):
  File "/usr/local/lib/python3.13/multiprocessing/process.py", line 313, in _bootstrap
    self.run()
    ~~~~~~~~^^
  File "/usr/local/lib/python3.13/multiprocessing/process.py", line 108, in run
    self._target(*self._args, **self._kwargs)
    ~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.13/site-packages/uvicorn/_subprocess.py", line 80, in subprocess_started
    target(sockets=sockets)
    ~~~~~~^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.13/site-packages/uvicorn/server.py", line 66, in run
    return asyncio.run(self.serve(sockets=sockets))
           ~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.13/asyncio/runners.py", line 195, in run
    return runner.run(main)
           ~~~~~~~~~~^^^^^^
  File "/usr/local/lib/python3.13/asyncio/runners.py", line 118, in run
    return self._loop.run_until_complete(task)
           ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^^^^^^
  File "/usr/local/lib/python3.13/asyncio/base_events.py", line 725, in run_until_complete
    return future.result()
           ~~~~~~~~~~~~~^^
  File "/usr/local/lib/python3.13/site-packages/uvicorn/server.py", line 70, in serve
    await self._serve(sockets)
  File "/usr/local/lib/python3.13/site-packages/uvicorn/server.py", line 77, in _serve
    config.load()
    ~~~~~~~~~~~^^
  File "/usr/local/lib/python3.13/site-packages/uvicorn/config.py", line 441, in load
    self.loaded_app = self.loaded_app()
                      ~~~~~~~~~~~~~~~^^
  File "/app/src/stac_auth_proxy/app.py", line 32, in create_app
    settings = settings or Settings()
                           ~~~~~~~~^^
  File "/usr/local/lib/python3.13/site-packages/pydantic_settings/main.py", line 177, in __init__
    super().__init__(
    ~~~~~~~~~~~~~~~~^
        **self._settings_build_values(
        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    ...<26 lines>...
        )
        ^
    )
    ^
  File "/usr/local/lib/python3.13/site-packages/pydantic/main.py", line 214, in __init__
    validated_self = self.__pydantic_validator__.validate_python(data, self_instance=self)
pydantic_core._pydantic_core.ValidationError: 9 validation errors for Settings
upstream_url
  Input should be a valid URL, relative URL without a base [type=url_parsing, input_value='"https://montandon-eoapi-stage.ifrc.org/stac/"', input_type=str]
    For further information visit https://errors.pydantic.dev/2.10/v/url_parsing
oidc_discovery_url
  Input should be a valid URL, relative URL without a base [type=url_parsing, input_value='"https://goadmin.ifrc.or...n/openid-configuration"', input_type=str]
    For further information visit https://errors.pydantic.dev/2.10/v/url_parsing
oidc_discovery_internal_url
  Input should be a valid URL, relative URL without a base [type=url_parsing, input_value='""', input_type=str]
    For further information visit https://errors.pydantic.dev/2.10/v/url_parsing
healthz_prefix
  String should match pattern '^/.*$' [type=string_pattern_mismatch, input_value='"/healthz"', input_type=str]
    For further information visit https://errors.pydantic.dev/2.10/v/string_pattern_mismatch
openapi_spec_endpoint
  String should match pattern '^/.*$' [type=string_pattern_mismatch, input_value='null', input_type=str]
    For further information visit https://errors.pydantic.dev/2.10/v/string_pattern_mismatch
public_endpoints
  Input should be a valid dictionary [type=dict_type, input_value='{\n  "^/api.html$": ["GE.../healthz": ["GET"]\n}\n', input_type=str]
    For further information visit https://errors.pydantic.dev/2.10/v/dict_type
private_endpoints
  Input should be a valid dictionary [type=dict_type, input_value='{\n  "^/collections$": [..._items$": ["POST"]\n}\n', input_type=str]
    For further information visit https://errors.pydantic.dev/2.10/v/dict_type
items_filter.args
  'str' instances are not allowed as a Sequence value [type=sequence_str, input_value='[]', input_type=str]
items_filter.kwargs
  Input should be a valid dictionary [type=dict_type, input_value='{}', input_type=str]
    For further information visit https://errors.pydantic.dev/2.10/v/dict_type

I think this may be me not adding new required variables, but some of these are a bit confusing / unexpected to me.

I've verified that OIDC_DISCOVERY_URL and UPSTREAM_URL env vars are correctly set in the container:

OIDC_DISCOVERY_URL="https://goadmin.ifrc.org/o/.well-known/openid-configuration"
UPSTREAM_URL="https://montandon-eoapi-stage.ifrc.org/stac/"

@alukach I think this will be a lot quicker to debug if we can pair 👀 on it quickly. Let me know if you have a bit of time once you're up. Thanks! We are definitely almost there.

[sunu]

@batpad from the error message, looks like some of those urls have an extra pair of quotes around them?

[batpad]

@batpad from the error message, looks like some of those urls have an extra pair of quotes around them?

Where do you get your eyes from. Nice catch. Can try a couple things. But that's strange.

[batpad]

@sunu that was it :-) - so that error is fixed.

[emmanuelmathot]

Maybe as a follow-up to ensure that helm chats is tested properly, a CI/CD test deploy like for titiler is useful

[batpad]

@emmanuelmathot haa I was just looking into adding tests, but will do that as a separate PR. Thanks for the pointer! I'll open a separate ticket about that and would be good to get your thoughts on the multiple possible approaches to testing that I've been looking into a bit.

[emmanuelmathot]

Sure. eoapi has similar but slightly more complex tests: https://github.com/developmentseed/eoapi-k8s/blob/main/.github/workflows/helm-tests.yml