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.
- Lookup k8s clusters via the API (v1/management/DBaaS/List) e.g.
- Request config for the cluster (v1/management/DBaaS/Get) e.g. for cluster ABC
The k8s config is extracted, but it cannot be used due to the token being removed for the percona-dbaas-cluster-operator user:
The token to appear, so that the config is usable.
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.
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.