You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
KubeZoo supports identifying tenants with service account tokens by transparently passing tokens to the upstream cluster. That is, kubezoo does not need to authenticate tenants, while the upstream cluster authenticates them.
Why is this needed?
Currently, KubeZoo supports identifying tenants with service account tokens. This requires the admin to provide sa.pub and sa.key of the upstream cluster when deploying KubeZoo. However, users cannot access sa.pub and sa.key on some public clouds.
Therefore, KubeZoo needs to support using service account tokens to identify tenants without sa.pub and sa.key.
The text was updated successfully, but these errors were encountered:
Related: #29 is blocking on this issue and/or #34 since the coredns pod should authenticate as the tenant using its own serviceaccount in the tenant namespace.
What would you like to be added?
KubeZoo supports identifying tenants with service account tokens by transparently passing tokens to the upstream cluster. That is, kubezoo does not need to authenticate tenants, while the upstream cluster authenticates them.
Why is this needed?
Currently, KubeZoo supports identifying tenants with service account tokens. This requires the admin to provide sa.pub and sa.key of the upstream cluster when deploying KubeZoo. However, users cannot access sa.pub and sa.key on some public clouds.
Therefore, KubeZoo needs to support using service account tokens to identify tenants without sa.pub and sa.key.
The text was updated successfully, but these errors were encountered: