Unable to extract a usable k8s config from the API

Impact on the user
Complicates accessing k8s as an administrator

Steps to reproduce

• Create PMM instance
• Create k8s cluster
• Register k8s cluster with PMM (graph/dbaas/kubernetes)
• Create netrc file (as used in examples) e.g.

  cat <<EOS > ~/.netrc
  machine localhost
  login admin
  password admin
  EOS
  chmod 0600 ~/.netrc
  

• Lookup k8s clusters via the API (v1/management/DBaaS/List) e.g.

  curl -k -X POST --netrc https://localhost/v1/management/DBaaS/Kubernetes/List

• Request config for the cluster (v1/management/DBaaS/Get) e.g. for cluster ABC

  curl -k -X POST --netrc https://localhost/v1/management/DBaaS/Kubernetes/Get --data {"kubernetes_cluster_name": "ABC"}'
  

Actual result
The k8s config is extracted, but it cannot be used due to the token being removed for the percona-dbaas-cluster-operator user:

users:
    - name: percona-dbaas-cluster-operator
      user: {}

Expected Result
The token to appear, so that the config is usable.

Workaround
Ensure that you have the token for the service account available so that the config can be modified and become usable, or have your own service account.

Details
Whilst removing AWS secrets (PMM-10561) from view in the UI, it appears that service account tokens for the operator have been hidden from the admin user, including via the API.

This poses some issues:

• it complicates the automation of an administrator's k8s config, because the YAML needs to be extracted from JSON and then modified, as well as limiting other automation possibilities
• it forces 2 sets of secrets to be shared; PMM access and k8s service account when managing another's PMM and DBaaS instances
• it does not prevent someone with access to the PMM instance from gaining these details, thus it cannot be argued that it has secured the service account token
• it means that even if the user is the person that registered the k8s instance with PMM then they are still unable to see the details that they put there in the first place

PMM provides little configuration options for clusters and so it is frequently necessary to use kubectl to apply configuration changes, such as setting MySQL configuration, when using DBaaS, hence the relevance of the k8s config.

It seems like this should be covered by RBAC to control access, but not completely remove it.

It appears that the removal of the service account was not an expected outcome of PMM-10561, which is why this is being raised.