Generic OIDC should support fetching tokens directly from HTTP endpoints

[timothyb89]

What would you like Teleport to do?

tbot/teleport should support fetching JWTs directly from HTTP endpoints in their client-side generic_oidc configuration, potentially including basic request headers.

It would probably also need some basic support for parsing the response, e.g. jsonpath or similar.

What problem does this solve?

Currently, the generic_oidc join method supports sourcing tokens from either environment variables or arbitrary commands. However, this is problematic when using Teleport's -distroless images: without any other binaries in the image to actually run, it's not possible to source JWTs.

Various providers make HTTP endpoints available for this purpose:

• Azure: http://169.254.169.254/ (https://learn.microsoft.com/en-us/azure/virtual-machines/instance-metadata-service?tabs=linux)
• GCP: http://metadata/ (https://docs.cloud.google.com/docs/authentication/get-id-token#metadata-server)

...however, without a tool like curl, these endpoints can't actually be fetched.

If a workaround exists, please include it.

Use a -debug image instead of distroless and use a curl command.

[marcoandredinis]

@timothyb89 Any ideas on how the UX for implementing this?

We have these fields currently:

  generic_oidc:
    # A command used to fetch a JWT. This can call a platform tool, a custom
    # helper you write, or a tool like `curl` to fetch a JWT from an internal
    # issuer. The first parameter is the executable to run, followed by any
    # arguments. Commands have a default timeout of 1m, which can be overridden.
    # Cannot be used with `env`.
    command: ["example-command", "issue-jwt", "--audience=example.teleport.sh/token"]

    # Overrides the default command timeout of 1m.
    # timeout: 1m

    # env is the name of an environment variable containing a JWT. This can be
    # used instead of `command` if the JWT you wish to authenticate with is
    # in an environment variable already. Cannot be used with `command`, and
    # `timeout` is ignored if set.
    # env: ENV_VAR_NAME

I can see us going either direction:
a) add another top level field describing the expected source of the jwt
b) add a field that would describe how to fetch the jwt from an http endpoint

For a), the UX would look like this:

  generic_oidc:
    source: "azure_container_instances"

Pros:

• simpler UX (less footguns)

Cons:

• each new provider requires code changes / new teleport versions

For b), the UX would look like this:

  generic_oidc:
    http_request:
      method: GET
      protocol: http
      host: 169.254.169.254
      path: metadata/identity/oauth2/token
      query_params:
        api-version: "2018-02-01"
        resource: https://management.azure.com/
      headers:
        Metadata: "true"
      jsonpath_jwt: .access_token

Or

  generic_oidc:
    http_request:
      method: GET
      url: "http://169.254.169.254/metadata/identity/oauth2/token?api-version=2018-02-01&resource=https%3A%2F%2Fmanagement.azure.com%2F"
      headers:
        Metadata: "true"
      jsonpath_jwt: .access_token

Pros:

• single implementation that supports multiple providers: eg, this would also automatically add support for GCP (which we don't need because all GCP compute runtimes are supported by our current gcp join method

Cons:

• more complex and error prone
• if we ever need to do 2 http requests, this will method can get very complex

---

Let me know what you think.
I want to work on this so that we add support for Azure Container Instances to join the cluster

[strideynet]

a) add another top level field describing the expected source of the jwt

Hm - I definitely appreciate this provides a better UX for the client-side configuration, but, we'd still be falling short of the UX we'd be able to offer by just implementing an out-of-the-box join method. My gut feeling is that we'd want to keep "Generic OIDC" as generic as possible.

[marcoandredinis]

Yeah, makes sense.
What about the other option?

We might require more complex flows, but for now, I think it would satisfy this use case without compromising on future flows.

As a more complex flow, we have the AWS IMDS v2 which requires two HTTP requests before obtaining the metadata: one for the token and another one for the actual metadata we want.
AWS is not relevant here because the iam join method supports everything (VM and container-VMs aka ECS) and they don't use OIDC.
I'm only bringing this as an example of a flow that requires two HTTP requests.

[strideynet]

We might require more complex flows, but for now, I think it would satisfy this use case without compromising on future flows.

Yeah - it may well be that it's "good enough for now". If someone has a truly complex flow, then it's likely either better:

• Implemented using a script
• Us adding an actual join method to support that provider.

I think my biggest concern w/ adding provider-specific functionality to the Generic OIDC join method is that it will make the intent/future direction a lot foggier. For anything common place, we really would prefer to add a distinct join method since this provides guard rails that make it significantly more secure than the Generic OIDC join method.

[marcoandredinis]

So, what do you think about the generic http request field?
@timothyb89 Any opinion here?

I wanted to get the high level design approval before starting the PR

[timothyb89]

I think the generic version (composing requests + jsonpath to parse the response) is a reasonable way forward. I'd just note that "JWT embedded in a field in a JSON response" is probably just one mode of the broader "responses that contain JWTs" so we should probably plan for other response types in the future.

In other words, maybe jsonpath_jwt solves for that use-case (mandates application/json content-type, requires valid json, parses with jsonpath) and would hypothetically live alongside other top-level fields, oneof style?