[user-authz] spec.subjects.name can't match User email if not lowercase

[meatuses]

Preflight Checklist

• [X] I agree to follow the Code of Conduct that this project adheres to.
• [X] I have searched the issue tracker for an issue that matches the one I want to file, without success.

Version

v1.56.9

Expected Behavior

User email should match case 1 to 1 with ClusterAuthorizationRule or AuthorizationRule's spec.subjects.name field (case sensitive), or be case insensitive and match any letter case.

Actual Behavior

Seems like User's email field is converted to lowercase by internal logic, but ClusterAuthorizationRule or AuthorizationRule spec.subjects.name field that should match that email is not converted. Currently you can't use any uppercase characters in authorization rule's spec.subjects.name as they wouldn't match the subjects.

Steps To Reproduce

1. Create User with email UserName@example.com (using any uppercase characters)
2. Create ClusterAuthorizationRule with spec.subjects.name UserName@example.com (matches email 1-1)
3. User won't have any permissions assigned by this CAR.
4. Change ClusterAuthorizationRule spec.subjects.name to username@example.com (manually set lowercase)
5. User's email is kept UserName@example.com
6. User has permissions given by the CAR

Additional Information

manifests that were used to test this:

apiVersion: deckhouse.io/v1
kind: User
metadata:
  name: username-test
spec:
  email: UserName@example.com
  password: password
---
apiVersion: deckhouse.io/v1
kind: ClusterAuthorizationRule
metadata:
  name: car-username
spec:
  subjects:
    - kind: User
      name: UserName@example.com
  accessLevel: SuperAdmin

Logs

No response

[konstantin-axenov]

kubectl auth whoami can be used for now to get information about current user. It helps to set correct ClusterAuthorizationRule.

[yalosev]

This problem is not solved head-on. We cannot convert subjects to ClusterAuthorizationRule because they may contain not only emails from our resources, but also from users' resources. This task probably requires a redesign of the OIDC claim from email to user and should be resolved as part of a more global RBAC redesign.