doctl is the main DigitalOcean CLI. While I have been able to get doctl working smoothly in strict confinement for our other offerings, the sane solution to interacting with k8s is to use classic confinement until there’s a defined interface for k8s configuration for use with kubectl. More detail on the issue here.
Once there’s a solution in place for interacting with k8s config, we will be happy to switch back to strict confinement.
Hi @reviewers & @advocacy teams,
Is there any further information we can provider here to help with this request?
I commented in Help please: kubectl + doctl strictly confined. The issue in the snap packaging/doctl laucher doesn’t justify classic and should be resolvable under strict confinement.
I have a solution that works under strict confinement now. It uses two personal-files interfaces; one for doctl’s config file and one for kubectl’s config file.
Should I open a new post to discuss autoconnecting the interfaces? If so, one new post for each? Convert this post to discuss?
Thanks
This post is fine. Please paste your plugs from the yaml and discuss why you need it.
The doctl snap uses two personal-files plugs as follows:
plugs:
kube-config:
interface: personal-files
write:
- $HOME/.kube
- $HOME/.kube/config
doctl-config:
interface: personal-files
write:
- $HOME/.config
- $HOME/.config/doctl
- $HOME/.config/doctl/.config
doctl needs write access to the kube-config plug so devs can use kubectl to interact with k8s clusters they created using doctl. For example:
doctl k8s cluster create madhavi
> Notice: cluster is provisioning, waiting for cluster to be running
...............
> Notice: cluster created, fetching credentials
> Notice: adding cluster credentials to kubeconfig file found in "/home/hilary/.kube/config"
> Notice: setting current-context to do-sfo2-madhavi
doctl k8s cluster kubeconfig save madhavi
> Notice: adding cluster credentials to kubeconfig file found in "/home/hilary/.kube/config"
> Notice: setting current-context to do-sfo2-madhavi
kubectl --context do-sfo2-madhavi get nodes
NAME STATUS ROLES AGE VERSION
madhavi-default-pool-o770 NotReady <none> 42s v1.14.1
madhavi-default-pool-o771 NotReady <none> 50s v1.14.1
madhavi-default-pool-o77d NotReady <none> 32s v1.14.1
The doctl-config plug is different. Using it is a matter of software engineering (at least I think so). A clean solution vs a brittle one.
kubectl uses the exec credential cached by doctl under doctl's config directory to auth, so that exec credential needs to be stored outside of the doctl confinement. I could check whether I am running inside a snap and move just that credential in that circumstance, although I’m now embedding yet more knowledge about snaps into the doctl code, which is going to create maintenance headaches down the road.
Without the doctl-config plug, I would also need to embed yet more snap-specific logic into the doctl code, assuming I’m not missing something. I experimented with not changing the value of $HOME, but rather setting $KUBECONFIG. Unfortunately, that doesn’t appear to work with the personal-files interface, which requires that the files start with $HOME/. As I have to set $HOME in the launcher for personal-files to work, that means I would have to override the config home directory for doctl when running as a snap (to $SNAP_USER_DATA?) without the doctl-config plug.
One the one hand, doctl can use a doctl-config plug. It needs write access as it is managing the data in the config file. It’s a clean solution from a software engineering viewpoint, however, the config file, including the cached credential, is in the user’s home directory, which isn’t great.
On the other hand, lots of snap-specific logic can get injected into the doctl code (yes, I’m doing my best to encapsulate it, but still). doctl would, quite literally, have to override (exec credential) an override (doctl config home) of an override (HOME) in order for everything to work. And the most sensitive information, the cached exec credential, would still be in the user’s home directory. (Although the access token would not.) As software quality is a huge component of security, I came down on the side of the plug, but I’m not married to the decision by any means.
I’m also hoping there’s another alternative I’m not aware of. 
Thanks!
A quick addendum. Now that I’ve merged the changes to master, I can’t promote new releases of the snap as it is not approved.
I’m assuming that’s due to the use of the personal-files interface, based on reading other threads asking for personal-files. Those threads quote messages concerning why the release isn’t approved - where would I find such a message?
Is there any other info we can provide to facilitate this request? @reviewers, @advocacy
Thanks
In the non-snap case, what is the normal location for this file?
It is clear that doctl is the owner of the .config/doctl directory. How well does doctl handle forward and backward compatibility of its configuration? Eg, if a user installed a deb/rpm/etc of doctl and the snap at the same time, and they were different versions, could the snap break the deb/rpm/etc or vice versa?
The normal location for the doctl config file is ~/.config/doctl/config.yaml, i.e., where the personal-files version of the snap puts the file.
doctl follows semver. While, in theory, we could do a major version change to signal a breaking change in the config file, we would only make that sort of change as part of a larger major change. Even then, we would detect and give clear messaging: doctl did make changes (moved the default location of the config file) in the shift from v0.x to v1.x, and includes both backward compatibility and messaging for v0.x files.
+1 for use of personal-files for kube-config. Since it is write access, currently -1 for auto-connection
+1 for use of and auto-connection of personal-files for doctl-config for write.
@reviewers - can others vote on this?
@jdstrand I was on the fence about auto-connecting kube-config myself. I could see arguments in both directions…
@popey Looks like you are a reviewer. Could you please review?
@reviewers What are the next steps here? The voting period has past, but it seems that we haven’t reached a quorum. Is there anything we can do to help move this along?
@reviewers - can some of you please vote?
+1 for use of, and auto-connection, for write to personal-files of doctl-config
+1 for use of personal-files for kube-config as well, but I agree with @jdstrand that auto-connection of write for this (since it is not owned by doctl) could be problematic - to create a good user experience however, I suggest using a wrapper script that first tests for write access to $HOME/.kube/config and if this fails, pop up a dialog (using zenity or yad etc) to the user to prompt them to manually connect the interface so that a good user experience can be maintained.
I agree with @jdstrand and @alexmurray.
On the topic of write access check - this is a command-line utility, so the prompt is even simpler.
3 votes for, 0 against for use of and auto-connection of personal-files for write to doctl-config
3 votes for, 0 against for use of personal-files for kube-config for write. 0 votes for, 3 against for auto-connection of kube-config for write.
Granted use of and auto-connection of personal-files for write to doctl-config. Granted use of personal-files for kube-config for write. This is now live.
Please adjust your snap.yaml to have:
plugs:
doctl-config:
interface: personal-files
write:
- $HOME/.config/doctl
kube-config:
interface: personal-files
write:
- $HOME/.kube/config
Note, there is a corresponding update has been made to the review-tools, but it is not in production yet. Once your snap.yaml uses the above and the review-tools update is in production, this will pass automated review. Until the review-tools are in production, new revisions will need to be manually approved.
Thanks for all your help @jdstrand!
The stanza from snapcraft.yaml that I have (that works locally) is:
plugs:
kube-config:
interface: personal-files
write:
- $HOME/.kube
- $HOME/.kube/config
doctl-config:
interface: personal-files
write:
- $HOME/.config
- $HOME/.config/doctl
- $HOME/.config/doctl/.config
doctl config file is $HOME/.config/doctl/.config