Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Talos API: Support OIDC #5192

Closed
flokli opened this issue Mar 24, 2022 · 7 comments
Closed

Talos API: Support OIDC #5192

flokli opened this issue Mar 24, 2022 · 7 comments
Labels

Comments

@flokli
Copy link
Contributor

flokli commented Mar 24, 2022

Feature Request

On a fresh install, talosconfig contains a 10 year valid certificate, signed by the CA from machine.ca.crt.

While it's possible to create a shorter-living and more restricted talosconfig, by picking a shorter --crt-ttl and a more restricted role via --roles:

❯ talosctl config new

Usage:
  talosctl config new [<path>] [flags]

Flags:
      --crt-ttl duration   certificate TTL (default 87600h0m0s)
  -h, --help               help for new
      --roles strings      roles (default [os:admin])

Global Flags:
      --context string       Context to be used in command
  -e, --endpoints strings    override default endpoints in Talos configuration
  -n, --nodes strings        target the specified nodes
      --talosconfig string   The path to the Talos configuration file

… there's no OIDC support in Talos API.

@smira
Copy link
Member

smira commented Mar 24, 2022

As Talos API is really low-level, and e.g. networking might be restricted (blocking OIDC requests), what we considered as an option: having external system handle OIDC and issue client certs. Also we could add additional certs to the machine configuration so that Talos will accept client certs issued by extra CAs (which might live in the external PKI system)

@flokli
Copy link
Contributor Author

flokli commented Mar 24, 2022

The idea would be a similar support as kube-apiserver - if enabled, the Talos API itself only periodically fetches JWKS.

Users can keep using client certs for auth, or if they present a valid JWT, only the things in the tokens are considered (so assuming fat tokens, no profile lookup by the apiserver)

@Ulexus
Copy link
Contributor

Ulexus commented Mar 24, 2022

I'm in the process of designing exactly this. However, as Andrey says, it's going to take a number of changes in the way we handle authentication. It's definitely something we want to support, but it will take some time.

@Ulexus
Copy link
Contributor

Ulexus commented Mar 24, 2022

See rfcs/8

@flokli
Copy link
Contributor Author

flokli commented Apr 11, 2022

Seems to be a dup of #3306 ?

Copy link

github-actions bot commented Jul 4, 2024

This issue is stale because it has been open 180 days with no activity. Remove stale label or comment or this will be closed in 7 days.

@github-actions github-actions bot added the Stale label Jul 4, 2024
Copy link

github-actions bot commented Jul 9, 2024

This issue was closed because it has been stalled for 7 days with no activity.

@github-actions github-actions bot closed this as not planned Won't fix, can't repro, duplicate, stale Jul 9, 2024
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Sep 7, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

No branches or pull requests

3 participants