Skip to content

Conversation

ricoberger
Copy link
Member

This is a complete rework of the authentication / authorization
middleware used in kobs. We do not longer depend on the teams array in a
User CR or on a default Team CR to authorize a user. Instead we are only
using the values from the provided user and teams header to get the
permissions of a user when the auth middleware is enabled.

For that we also updated the Custom Resource Definition for Users and
Teams. Both CRDs can be used to define the permissions for a user. For
that both CRDs now have an "id" field which must be unique across all
clusters and namespaces. If a user is part of multiple teams we merge
the permissions of all teams for the user.

To reduce the number of Kubernetes API calls, we save the user
information now in a cookie, which contains a signed JWT token with the
users profile and permissions. We automatically try to refresh the JWT
token when it is expired. If the token could not be refreshed we return
an unauthorized error.

When the auth middleware is disabled, we still try to get the user id
from the defined user header and inject it into the request context.
This way we can simplify the auth handling in some plugins, because we
always have a valid user object in the context and the user id can be
used for a lightweighted audit logging.

This is a complete rework of the authentication / authorization
middleware used in kobs. We do not longer depend on the teams array in a
User CR or on a default Team CR to authorize a user. Instead we are only
using the values from the provided user and teams header to get the
permissions of a user when the auth middleware is enabled.

For that we also updated the Custom Resource Definition for Users and
Teams. Both CRDs can be used to define the permissions for a user. For
that both CRDs now have an "id" field which must be unique across all
clusters and namespaces. If a user is part of multiple teams we merge
the permissions of all teams for the user.

To reduce the number of Kubernetes API calls, we save the user
information now in a cookie, which contains a signed JWT token with the
users profile and permissions. We automatically try to refresh the JWT
token when it is expired. If the token could not be refreshed we return
an unauthorized error.

When the auth middleware is disabled, we still try to get the user id
from the defined user header and inject it into the request context.
This way we can simplify the auth handling in some plugins, because we
always have a valid user object in the context and the user id can be
used for a lightweighted audit logging.
@ricoberger ricoberger force-pushed the core-rework-auth-middleware branch from 2054472 to cf74759 Compare December 22, 2021 22:09
@ricoberger ricoberger merged commit 3ea5105 into main Dec 22, 2021
@ricoberger ricoberger deleted the core-rework-auth-middleware branch December 22, 2021 22:28
ricoberger added a commit that referenced this pull request Dec 24, 2021
The documentation about the permission handling in the Azure plugin was
outdated, after #241. This commit fixes the documentation, so that we
are now showing the correct examples, how the permissions for the Azure
plugin can be set for a user / team.
ricoberger added a commit that referenced this pull request Dec 24, 2021
The documentation about the permission handling in the Azure plugin was
outdated, after #241. This commit fixes the documentation, so that we
are now showing the correct examples, how the permissions for the Azure
plugin can be set for a user / team.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant