Uploaded image for project: 'Percona Monitoring and Management'
  1. Percona Monitoring and Management
  2. PMM-11414

Unable to extract a usable k8s config from the API


    • Bug
    • Status: On Hold
    • Medium
    • Resolution: Unresolved
    • 2.33.0
    • None
    • None
    • Yes
    • Yes
    • No


      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
        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:

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

      Expected Result
      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.


        Issue Links



              Unassigned Unassigned
              ceri.williams Ceri Williams
              0 Vote for this issue
              2 Start watching this issue



                Smart Checklist