T4K UI supports authentication through kubeconfig files - token, certificate, auth-provider, etc. As a result, any user of the Kubernetes cluster can log into the UI, view information, and perform operations based on their permissions and authorization as per their RBAC.
'Exec' or 'Auth Provider' flags in Kubeconfig
Some Kubernetes clusters may contain cloud-specific exec action or use auth-provider configuration to fetch the authentication token within the kubeconfig file. Since the binaries for the specific cloud service may not available on the setup where the user is providing the config file, T4K may not be able to fetch the token and populate it in the kubeconfig.
In order to support authentication for these cloud providers, follow the steps below to create a kubeconfig file with a custom kubeconfig consisting of a service account token and cluster data.
Create a Service Account
To create a service account on Kubernetes, leverage kubectl and a service account spec. Create a YML file name sa.yml that looks like the one below:
apiVersion: v1
kind: ServiceAccount
metadata:
name: svcs-acct-dply #any name you'd like
Create the service account:
kubectl create -f sa.yaml
To create a service account token on Kubernetes. Create a YML file name sa-secret.yml that looks like the one below:
Copy two pieces of information from above certificate-authority-data and server
Create a kubeconfig file
From the steps above, you should have the following pieces of information
token
certificate-authority-data
server
Create a file called sa-kconfig and paste the following content to it
apiVersion: v1
kind: Config
users:
- name: svcs-acct-dply
user:
token: <replace this with token info>
clusters:
- cluster:
certificate-authority-data: <replace this with certificate-authority-data info>
server: <replace this with server info>
name: self-hosted-cluster
contexts:
- context:
cluster: self-hosted-cluster
user: svcs-acct-dply
name: svcs-acct-context
current-context: svcs-acct-context
Replace the placeholder above with the information gathered so far
replace the token
replace the certificate-authority-data
replace the server
You can either choose to export the created kubeconfig file after that or move/copy it to $HOME/.kube/ location
Create ClusterRole and ClusterRoleBinding
After you have your kubeconfig file ready and exported/moved to .kube/config, Create a RoleBinding to bind the service account created from the above steps with ClusterRole. The role should have minimum permission required to access the T4K.
GKE/EKS supported kubeconfig file use local credentials file to generate authentication token which can be used to access the kubernetes cluster. Hence, or refer to to use a workaround for using the credentials file to login T4K UI
DigitalOcean supports download of the kubeconfig file directly from the Kubernetes cluster page shown under "Access Cluster Config File" which can be used for authentication to the Trilio Management Console.
If you are using doctl CLI to generate a kubeconfig file, it contains an exec section with custom commands that may not be recognized by the Trilio Management Console. Hence, or refer to to use a workaround for the kubeconfig generated through doctl.
