Request access 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.