Automatic connection request for un-seal

store-requests privileged-interfaces
1
  • name: un-seal
  • description: un-seal is a Juju helper Snap designed to automate the initialization, unsealing, and authorization of Vault applications deployed via Juju. Deploying a charmed Vault with Juju requires a specific sequence of operations to bootstrap the cluster: initializing the Vault operator, securely managing the generated unseal keys and root token, unsealing individual units, and authorizing the charm to interact with the Vault API. un-seal streamlines this workflow into a single interactive command. It is designed for security-conscious environments, supporting split-file credential storage and GPG encryption (compatible with hardware tokens such as YubiKey) to facilitate the whole process.
  • snapcraft: snapcraft.yaml
  • upstream: GitHub Repo for un-seal
  • upstream-relation: upstream maintainer - author
  • interfaces:
    • juju-bin (content):
      • request-type: auto-connection
      • reasoning: Necessary to be able to use the Juju binary
    • dot-local-share-juju (personal-files):
      • request-type: auto-connection (or at least installation/connection)
      • reasoning: In order to be able to use Juju successfully, it needs read/write access to .local/share/juju
    • gpg-keys:
      • request-type: auto-connection (or at least installation/connection)
      • reasoning: Since the program encrypts and decrypts vault keys, it needs access to GPG, both public and private keys.
    • pcscd:
      • request-type: installation/connection
      • reasoning: It needs to access the PCSCD smart card daemon to be able to use YubiKey/smart cards
2

This request has been added to the queue for review by the @reviewers team.

3

Hey @pgdg99 , thanks for your contribution.

One question:

  1. Does the snap need write access to .local/share/juju file, if yes, can you explain a bit more why only read access is not sufficient.?

For gpg-keys, I am hesitant to give auto-connection, I think manual-connection is fine since user must know what they are granting. otherthan that, +1 for me content interface autoconnection, pcscd auto-connection given that we have a successful publisher vetting

#askForInfo

4

Hi @0xnishit , thanks for your answer,

At first, I tried using the juju-client-observe interface, which is read-only access, and I got the following error when trying to use Juju:

ERROR cannot load cookies: file locked for too long; giving up: cannot acquire lock: open /home/ubuntu/.local/share/juju/cookies/juju-3x-controller.json.lock: permission denied

So it basically can’t refresh the cookies, nor work with the lock files, thus making it fail. The only way I managed to solve it was by also giving it write permissions as well.

5

thanks for the information, it looks like write access is needed for the personal-files interface to this snap. +1 from my end for auto-connection (#voteFor)

6

Hey @pgdg99

Thanks for making un-sealwork under strict confinement!

Regarding juju-bin (content), I’m not against granting it but I wonder if it would be better to stage juju in your snap via stage-snaps. Any reason against this approach?

The other three interfaces look appropriate to me, I’m more on the manual connection side in this case as:

  • most juju users should be familiar enough with the terminal, so issuing snap connect commands should not be a problem for them
  • the project is not mature enough yet, so that bugs/vulnerabilities are likely to appear

The usual recommendation in these cases is to use snapctl is-connected to check whether an interface is connected in runtime and prompt the user to connect it if needed.

Thanks

7

Hi @jslarraz ,

I couldn’t bundle Juju with the snap since a bundled Juju would operate in isolation from the host’s installation, creating a disconnect between the active models and their underlying databases, which would either cause it to fail or prevent it from being used correctly.

Thanks for the snapctl suggestion, I’ll implement it as well.

8

In that case +1 from me (#voteFor) for granting un-seal

  • auto-connection to juju-bin interface
  • manual connection to dot-local-share-juju, gpg-keys and pcscd interfaces
9

Voting period has ended. This request is approved with 2 votes for and 0 votes against.

10

Hello @pgdg99! I will begin the vetting process, so we can proceed with granting the interfaces!

1 Like
11

Publisher is vetted and the interfaces are granted, this is now live! @pgdg99 could you please resubmit the snap for automatic review?