Classic confinement for kontena-lens

[jdstrand]

Thanks for the additional information.

@jakolehm

static client certificates (path can point to anywhere):

- name: minikube
  user:
    client-certificate: /home/jari/.minikube/client.crt
    client-key: /home/jari/.minikube/client.key

While the path could be anywhere, the user is in a position to configure the paths and so personal-files, home and removable-media are as sufficient for this as any other strict mode snap AFAICT and files outside the paths can be solved via documentation. Please confirm that it is the user of the host that is writing the kube config in question.

@jakolehm

authentication via executable (can be anything, anywhere in local filesystem):

- name: jari@eks-kontena-nvme.eu-north-1.eksctl.io
  user:
    exec:
      apiVersion: client.authentication.k8s.io/v1alpha1
      args:
      - token
      - -i
      - eks-kontena-nvme
      command: aws-iam-authenticator
      env:
      - name: AWS_PROFILE
        value: kontenalabs

This does require that aws-iam-authenticator (and therefore all the popular auth helpers) be packaged in the snap, which is where I was saying snapcraft parts could help. In practice, how many popular/standard auth helpers are there? 5, 10, 50? Do the auth helpers change often and/or are they specific to particular versions of k8s or the providers (eg, is there just one aws-iam-authenticator that can handle all versions of aws auth or are there several/many and the developer has to pick the right one for his/her specific deployment?)

@jakolehm

authentication via auth-provider (google uses this):

- name: gke_svc-vodka_europe-north1_jakolehm-europe-north1
  user:
    auth-provider:
      config:
        cmd-args: config config-helper --format=json
        cmd-path: /usr/local/Caskroom/google-cloud-sdk/latest/google-cloud-sdk/bin/gcloud
        expiry-key: '{.credential.token_expiry}'
        token-key: '{.credential.access_token}'
      name: gcp

This one requires classic since /usr/local is not in the snap’s runtime. That said, if the gcloud helper were in the snap, this wouldn’t be needed (see above; do the various providers fragment their individual auth helpers or is there one auth helper for each provider that is expected to work (eg, where the snapcraft part can always pull the latest for a particular provider and it could be expected to work everywhere for that provider))?