Personal-files for kconnect

Hello,

Would it be possible to get approval for personal-files to read/write the following files:

  • $HOME/.aws/credentials
  • $HOME/.kube/config

kconnect is a CLI utility that discover Kubenetes clusters and creates the Kubenetes config for a selected cluster. Its designed to be a companion to kubectl (https://snapcraft.io/kubectl).

It requires access to those files to create a kubconfig and also save AWS credentials…both of which are required for kubectl access to access managed Kubernetes servers in AWS (i.e. EKS).

Thanks,

Rich

The user has the ability to specify where they would like their kubeconfig written to and this could be where ever they decide on their system.

Would classic confinement be better?

This isn’t typically a justification for classic since the user can use the typical location (or anywhere in SNAP_USER_DATA, SNAP_USER_COMMON, etc) with your snap guiding and helping to facilitate that.

Before we go down that path, does kconnect require the use of arbitrary authentication agents, or will it always use AWS in predictable ways?

Thanks for the response @jdstrand.

This utility is designed to work as a companion to kubectl (https://snapcraft.io/kubectl). Users of kubectl are used to being able to use a kubeconfig that is located anywhere on their system (but the default is $HOME/.kube/config). kconnect is a utility that helps to generate the kubeconfig files for use by kubectl and like kubectl it allows the user to store the kubeconfig file where they choose. I could be wrong but this feels like classic?

To answer the question:

does kconnect require the use of arbitrary authentication agents, or will it always use AWS in predictable ways?

At present kconnect only discovers clusters in AWS (using SAML). However, we will be adding support discovering clusters in Azure and Rancher soon with other providers potentially added in the future. There are plans to support identity protocols other than SAML, such as Azure AD and OAuth/OIDC and corresponding identity providers like Azure, Ping, Auth0 .

@richcase will these other clusters require other authentication agents? Will these be able to be provided by the kconnect snap or would they have to already exist on the host machine?

@alexmurray - the Kubernetes clusters that are ultimately connected with a kubeconfig that is generated by kconnect could have other authentication agents but these will already be installed on the clusters. kconnect will have no part in that.

The job of kconnect is to discover Kubernetes clusters in a provider (i.e. AWS, Azure, Rancher) and create a config file for kubectl to use later.

@alexmurray - it will use other authentication agents (as kubectl does)…it just won’t install those agents.

@alexmurray @jdstrand - just wondering if there was an update on this request?

(i’ve also updated the title)

I think there was a misunderstanding of what kconnect’s use cases are originally - from what I understand kconnect is just generating a config file that kubectl (which is expected to already exist on the host system) will later use - as such, the original request for personal-files seems a lot more appropriate if anything since it just needs to write out a config file. The other option is it could write out the config file in say just $SNAP_USER_DATA and then ask the user to manually place this in a location where kubectl can find it. Can you please clarify?

Thanks @alexmurray.

Yes thats right. kconnect will query AWS/Azure and then generate a config file for kubectl to use.

I don’t think its really feasible to ask users to copy the generated file as this isn’t great user experience. And kconnect will add/merge an existing config file with the connections details of the selected cluster.

If you think personal files is better then that may work. However, i have a doubt as kconnect (like kubectl) doesn’t restrict where a config file can be.

Unfortunately the requirement that users may want to write / read configs from arbitrary locations is not a supported use-case for classic confinement (as @jdstrand mentioned originally). However, personal-files should allow kconnect to be granted access to the most common paths if they are not already available via the home interface - so this should still provide a good user experience.

So I think this thread should revert back to a request for personal-files for the original two locations.

One thing however to note - the currently specified personal-files access for kconnect has a few issues - can you please change it to be as follows:

apps:
  kconnect:
    command: kconnect
    plugs:
    - home
    - network
    - dot-aws-credentials
    - dot-kube-config
plugs:
  dot-aws-credentials:
    interface: personal-files
    write:
    - $HOME/.aws/credentials
  dot-kube-config:
    interface: personal-files
    write:
    - $HOME/.kube/config

ie. write implies read so there is no need to list both, and personal-files instances should be named so that users understand what is being granted - hence the use of two separate instances, each with a descriptive name.

Thanks @alexmurray. I’ve made the title change and also the change to the plugs and published a new version…its been flagged for manual review.

+1 to grant installation of personal-files with write access to $HOME/.aws/credentials with the interface reference dot-aws-credentials.

+1 to grant installation of personal-files with write access to $HOME/.kube/config with the interface reference dot-kube-config.

@reviewers - can others please vote?

+1 from me too for both of these personal-files accesses - the stated purpose of kconnect is to create configurations that kubectl etc will use and since kubectl will load them from these locations it makes perfect sense for kconnect to be able to write to these OOTB.

+2 votes for, 0 votes against, granting use and auto-connect of these personal-files instances, this is now live.