Automate m2m oc/kubectl communication

Todo

Summary : Automate m2m oc/kubectl communication between a job running as .github/workflow and RHTAP ocp4 clusters running on console.redhat.com

Use case description: The use case should be to support to automate tests running part of a github flow where the oc or kubectl client will execute commands against RHTAP (= ocp clusters running here https://console.redhat.com/preview/hac/application-pipeline) AND without the need to use a personal red hat account but instead a service account.

The use case will require to have/support:

Red Hat Service account. Such account can be created here: https://console.redhat.com/preview/application-services/service-accounts. They include an clientId and secretId which can used part of a query to get a token from the OIDC provider: https://sso.redhat.com/auth/realms/redhat-external/protocol/openid-connect/token)
To map a ServiceAccount to a SSO group (= which should be mapped too to a RBAC)
Have RBAC defined for the SA's groups
Generate a random namespace or a namespace defined according to the convention: service_account_name_uid
Create the namespace and apply the RBAC to the group
Delete the namespace when SA are deleted or expire on sso.redhat.com

We can configure locally the kubectl/oc client (= kube config) to use the token but the ocp's RHTAP cluster will fail to authenticate the OIDC token as they are not configured to accept the OIDC token. See such a config here: https://medium.com/@charled.breteche/kind-keycloak-securing-kubernetes-api-server-with-oidc-371c5faef902

According to Alexey Kazakov, the RHTAP Proxy accepts as OIDC parameters:

sub claim (OK) -> 721e665b-93d9-4c12-a772-b69eaee5905a
email claim (NOK)
preferred_username claim (NOK) -> service-account-391f1c4c-fe45-4935-bcee-667b075a9962

Example of OIDC response received using clientId and SecretID

#### Id token decoded: {
  "exp": 1692634304,
  "iat": 1692633404,
  "auth_time": 0,
  "jti": "288488d7-2603-4fff-a359-a08f1b228bc5",
  "iss": "https://sso.redhat.com/auth/realms/redhat-external",
  "aud": "391f1c4c-fe45-4935-bcee-667b075a9962",
  "sub": "721e665b-93d9-4c12-a772-b69eaee5905a",
  "typ": "ID",
  "azp": "391f1c4c-fe45-4935-bcee-667b075a9962",
  "at_hash": "poKLFijn4MzLPb-SkuHGcw",
  "clientHost": "2a02:a03f:b90f:b800:e420:6d08:dff0:e759",
  "clientId": "391f1c4c-fe45-4935-bcee-667b075a9962",
  "email_verified": false,
  "rh-user-id": "50986588",
  "rh-org-id": "10977452",
  "preferred_username": "service-account-391f1c4c-fe45-4935-bcee-667b075a9962",
  "clientAddress": "2a02:a03f:b90f:b800:e420:6d08:dff0:e759"
}

According to Alexey Kazakov, the preferre_username is the service account name but not the username which generated the SA token. So, we can't map the sso SA to any RHTAP workspace. Right now we require a username because we can tell if this user has permissions to work with specific workspace. We have no idea if some random SA issued by sso has any permissions in a specific workspace (well… we know it doesn’t).

Suggestions to solve it:

“registering” SAs in the workspace. Like adding users to the workspace but instead adding SAs. We don’t have it atm.
Another option is for sso start supporting user groups. Then we could manage groups on sso (for users and SAs). And also we would need to support groups on the RHTAP side. Then you just grand permissions to groups on the RHTAP side but then can add users and SAs to the groups on the sso side.

Remark: Such a demand already exists https://issues.redhat.com/browse/CRCPLAN-185

redhat-buildpacks / testing

Automate m2m oc/kubectl communication #39

Todo