When a user authenticates to a cluster via Token Credential Request, we should check their username and groups against the cluster's cluster role bindings and role bindings. As long as they have some (valid?) binding that references them, we should allow the request to succeed. Otherwise we should fail the request as Unauthorized. To support clusters that do not use RBAC, we should define some custom cluster scoped SAR that we can test against, i.e. verb=logingroup=virtual.pinniped.devresource=authorization.cluster.pinniped.dev. We would include the definition of this custom SAR in a predefined cluster role that the cluster admin could bind to system:authenticated should they wish to bypass this functionality all together.
Note that this is important because being in the system:authenticated group grants a certain level of access to the cluster (i.e. discovery) and I think it would match end user expectations better if authentication had to be explicitly allowed.
When a user authenticates to a cluster via Token Credential Request, we should check their username and groups against the cluster's cluster role bindings and role bindings. As long as they have some (valid?) binding that references them, we should allow the request to succeed. Otherwise we should fail the request as
Unauthorized
. To support clusters that do not use RBAC, we should define some custom cluster scoped SAR that we can test against, i.e.verb=login
group=virtual.pinniped.dev
resource=authorization.cluster.pinniped.dev
. We would include the definition of this custom SAR in a predefined cluster role that the cluster admin could bind tosystem:authenticated
should they wish to bypass this functionality all together.Note that this is important because being in the
system:authenticated
group grants a certain level of access to the cluster (i.e. discovery) and I think it would match end user expectations better if authentication had to be explicitly allowed.