-
Notifications
You must be signed in to change notification settings - Fork 19
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
Add support for user impersonation #125
Labels
Comments
Hey @UiP9AV6Y, Thanks for your suggestion of using an optional feature to impersonate users by reading header Informations. Would you like to assist us to implement this feature? I like the idea of your proposed concept. Feel free to contribute to our project. If you want us to implement the feature, it can take some time. Best regards. |
Jaydee94
added
enhancement
New feature or request
and removed
bug
Something isn't working
labels
Feb 23, 2022
yes, i will provide a PR |
UiP9AV6Y
added a commit
to UiP9AV6Y/kubeseal-webgui
that referenced
this issue
Mar 4, 2023
instead of using the namespace endpoint, the API can use any arbitrary resource list endpoint and extract the available namespaces from their metadata. related to Jaydee94#125
UiP9AV6Y
added a commit
to UiP9AV6Y/kubeseal-webgui
that referenced
this issue
Mar 4, 2023
instead of using the namespace endpoint, the API can use any arbitrary resource list endpoint and extract the available namespaces from their metadata. related to Jaydee94#125
UiP9AV6Y
added a commit
to UiP9AV6Y/kubeseal-webgui
that referenced
this issue
Mar 4, 2023
instead of using the namespace endpoint, the API can use any arbitrary resource list endpoint and extract the available namespaces from their metadata. related to Jaydee94#125
UiP9AV6Y
added a commit
to UiP9AV6Y/kubeseal-webgui
that referenced
this issue
Mar 4, 2023
instead of using the namespace endpoint, the API can use any arbitrary resource list endpoint and extract the available namespaces from their metadata. related to Jaydee94#125
UiP9AV6Y
added a commit
to UiP9AV6Y/kubeseal-webgui
that referenced
this issue
Mar 5, 2023
instead of using the namespace endpoint, the API can use any arbitrary resource list endpoint and extract the available namespaces from their metadata. related to Jaydee94#125
UiP9AV6Y
added a commit
to UiP9AV6Y/kubeseal-webgui
that referenced
this issue
Mar 8, 2023
instead of using the namespace endpoint, the API can use any arbitrary resource list endpoint and extract the available namespaces from their metadata. related to Jaydee94#125
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
users request the namespaces from the kubeseal-webui api,
which in return accesses the kubernetes api using a service
account.
given that the role associated with the service account has
not restrictions on which namespace it can see, all available
namespaces are returned. therefor a user can see all namespaces
even when they themself have no access to it.
kubernetes support impersonating users when performing
requests against its API, which would allow the kubeseal-webui
API to limit its namespace result to the namespaces relevant
to the current user.
currently kubeseal-webui has no concept of users and/or groups.
this information however can be passed on e.g. via headers.
proposal
add support for reading user information from request headers,
and use it to dispatch impersonated kubernetes api requests.
we have deployed kubeseal-webui behind a reverse proxy which
performs user authentication and can forward the authentication
information via headers (e.g.
X-Forwarded-User
).given that the impersonation support in the python library
is limited, i would suggest to limit impersonation to
users for now (as opposed to users and groups)
this feature must be explicitly enabled by admins in environments
where the authentication information can be trusted, otherwise
users can make requests with rogue authentication headers:
use provided user information and dispatch kubernetes
requests with impersonation information
incoming header to look for user information. if empty/not
set, downstream requests to the kubernetes API will not
be made just as before (i.e. without any impersonation data)
the role resource must also be adjusted, to include the
impersonation permission (must also be explicitly enabled)
The text was updated successfully, but these errors were encountered: