Use ExecConfig in the kubectl client configuration

[ulrichSchreiner]

This PR changes the cluster kubeconfig command so that the configuration for a context does not contain a client-key-data but instead a execution configuration so kubectl will invoke metal to lazy fetch the data. This data is written in a cache file and when it expires an new one will be fetched.

The user needs a valid METAL_API_TOKEN and with every refresh this token is checked if it is still valid. So you do not need a long expiration for the kubeconfig.

This implementation adds a subcommand exec-config which itself has a duration. I think this duration can be removed or at least limited to a very short maximum (aka 3 or 7 days), so a user cannot get a configuration for too long. Any opinions?

There is also

APIVersion: "client.authentication.k8s.io/v1"

hardcoded. Afaik the v1beta must be used for K8s-Versions <1.24. I'm not sure if this is relevant here.

A user-entry in the kubeconfig could look like this

users:
- name: cp-test-default-project@metalstack.cloud
  user:
    exec:
      apiVersion: client.authentication.k8s.io/v1
      args:
      - cluster
      - exec-config
      - -p
      - <project-id>
      - <cluster-id>
      command: /home/usc/workspaces/ulrichSchreiner/cli/bin/metal-linux-amd64
      env: null
      interactiveMode: IfAvailable
      provideClusterInfo: false

where project-id and cluster-id will be filled with concrete values. The API-Key for the backend could be filled in the env block but imho it is better for a human user to have it in the concrete environment.

[Gerrit91]

Thanks, I think this is an awesome PR and I think it allows us to reduce the maximum duration for a kubeconfig.

[Gerrit91]

Sorry, by mistake I pushed this into our main instead of your main and your PR got automatically merged. 🙈