In case where there is a need to confirm a TMC user's group information, we can look at the kubeconfig file that was generated and downloaded from TMC. The information can then be compared against the expected group membership from the Identity Provider, or with the RBAC rules in the cluster.
VMware Tanzu Mission Control
The following steps detail how to examine the cluster credentials that were provided through TMC.
Download the kubeconfig file from TMC. This can be downloaded from the cluster page by clicking on the "Actions"->"Access this cluster"->"Download Kubeconfig File".
View the kubeconfig file using your favorite editor or viewer. Locate the ".users.user.exec.env" element.
e.g.,
users:
- name: example-name
user:
exec:
apiVersion: client.authentication.k8s.io/v1beta1
args:
- tmc
- cluster
- generate-token
command: tanzu
env:
- name: CLUSTER_UID
value: c:01XXXXXXXXXXXXXXXXXXXXV3XH
- name: CLUSTER_RID_V2
value: rid:c:0XXXX9999-XXXX-9999-XX99-XXX9X99X9999:example-mgmt:default:example-cluster
- name: CLUSTER_ENDPOINT
value: https://10.X.X.X:6443
- name: CLUSTER_CA_BUNDLE
value: LS0tLXXXXXeFlJeVhSRC92...
If using a Mac or Linux, open a terminal program, and export the following environment variables with values from the "env" element from the kubeconfig file.
export CLUSTER_UID=c:01XXXXXXXXXXXXXXXXXXXXV3XH
export CLUSTER_RID_V2=rid:c:0XXXX9999-XXXX-9999-XX99-XXX9X99X9999:example-mgmt:default:example-cluster
export CLUSTER_ENDPOINT=https://10.X.X.X:6443
export CLUSTER_CA_BUNDLE=LS0tLXXXXXeFlJeVhSRC92...
If using Windows, open a command prompt and set the following environment variables with values from the "env" element from the kubeconfig file.
set CLUSTER_UID=c:01XXXXXXXXXXXXXXXXXXXXV3XH
set CLUSTER_RID_V2=rid:c:0XXXX9999-XXXX-9999-XX99-XXX9X99X9999:example-mgmt:default:example-cluster
set CLUSTER_ENDPOINT=https://10.X.X.X:6443
set CLUSTER_CA_BUNDLE=LS0tLXXXXXeFlJeVhSRC92...
Run the command to request a generated token from TMC.
tanzu tmc cluster generate-token
From the output, locate the "clientCertificateDate" (client certificate) and "clientKeyData" (client key) values.
e.g.,
{
"kind": "ExecCredential",
"apiVersion": "client.authentication.k8s.io/v1beta1",
"spec": {
"interactive": false
},
"status": {
"expirationTimestamp": "2024-11-27T18:51:44Z",
"clientCertificateData": "-----BEGIN CERTIFICATE-----\nMIIEiDCCA3xxxxxxxx\n-----END CERTIFICATE-----\n",
"clientKeyData": "-----BEGIN PRIVATE KEY-----\nMIGHAxxxxxxxxxxxxxxxxxxx\n-----END PRIVATE KEY-----\n"
}
}
Save the client cert and key values into separate files.
e.g.,
$ printf -- "-----BEGIN CERTIFICATE-----\nMIIEiDCCA3xxxxxxxx\n-----END CERTIFICATE-----\n" > /tmp/myclient.crt
$ printf -- "-----BEGIN PRIVATE KEY-----\nMIGHAxxxxxxxxxxxxxxxxxxx\n-----END PRIVATE KEY-----\n" > /tmp/myclient.key
Use "openssl" command to examine the client certificate:
$ openssl x509 -in /tmp/myclient.crt -text -noout
From the output, you should see the "Subject" value, which would show the group membership information, if there is any. In this example, the example user ('[email protected]') is a member of the group "example-test-group".
Subject: O=example-test-group + O=tmc:member + O=csp:org_member, [email protected]
The information can then be compared against the expected group membership from the Identity Provider, or with the RBAC rules in the cluster.