Install via package managers

[SimonBarendse]

We'd like to distribute the CLI via package managers, so that it can be easily installed using the package manager you are used to.
e.g.

brew install secrethub

We'd like to support at least:

• brew
• snap

Other package managers we are considering are:

• apk
• choco
• apt-get
• yum
• scoop
• pacman/Arch User Repository
• NPM

We might add other package managers to this list. Please let us know if there's another package manager in which you'd like us to distribute the CLI.

[SimonBarendse]

Just released the brew tap! 🎉 You can now install secrethub using:

brew install secrethub/tools/secrethub-cli

[mackenbach]

Not really a package manager, but an .msi installer for windows is a legitimate install method I'd like to see. Windows folks tend to appreciate it a lot when we give them a pre-baked installer instead of a .zip with a binary and instructions.

@florisvdg already started work on this I see #58

[SimonBarendse]

+1 on the MSI installer.

---

That reminds me of another update for Windows users. You can now install using Scoop:

 scoop bucket add secrethub https://github.com/secrethub/scoop-secrethub 
 scoop install secrethub-cli

🎉

[SimonBarendse]

We have added the CLI to snap as well 🎉

[SimonBarendse]

yum support is added in v0.29.0.

[mackenbach]

And release v0.29.0 added .deb support as well.

[jpcoenen]

An MSI for v0.30.0 was released earlier today and a full YUM repository is now live at https://yum.secrethub.io. The latter can be installed with:

curl https://yum.secrethub.io/secrethub.repo -o /etc/yum/repos.d/secrethub.repo --create-dirs
yum install secrethub-cli

[jpcoenen]

SecretHub is now also in the Arch User Repository under the name secrethub-cli:

yay -S secrethub-cli

[stavalfi]

please add this to specific languages package-managers (e.g. npm).

why?

as this is used locally on the developer machines in specific projects, it will be easier to install this part of the dev-dependencies of the project.

so the developer won't need to manually install it on his machine.

but in most cases, a developer that has a small task on a side-project, doesn't want to deal with specific external tools that the project needs.

[mackenbach]

Ah that's a very valid use case @stavalfi I didn't think of it that way yet, but yes it makes quite a bit of sense to have it as a project dependency,. One thing though, the dev would need a secrethub account to be able to work with it so there is that 'hidden' dependency. What's your take on that?

[stavalfi]

thanks for the quick response :)

I started to use secrethub just couple of days ago so my opinion may not be based on expirience or usage statistics, and I also don't have any expirience in managing secrets overall. so please ignore it me you think otherwise.

---

in short, you can use the package manager to execute secrethub executable.

the long version:

As I understand, some (or most/all) of the team-members won't have much (or any) work to do on secrethub directly besides running a script from package.json that runs the project's tests using secrethub run command.

In node and javascript, we run commands using the package manager so each script will able to run any executable it needs without worring if the executable is in the PATH or not. so, for example, if I'm using yarn, I will login by running: yarn secrethub login (yarn let me execute executables from node_modules/.bin folder. or using npm: npm run secrethub-login and it will run the secript "secrethub-login": "secrethub login" from the package.json.

In addition, in ci-systems and in dockerfiles, I won't need to manage the secrethub installation seperatly. so I think I can't find a use case to not install it from the language-package-manager unless part of your job is to manage the secrerts for the project/company.

[SimonBarendse]

Hi @stavalfi, very interesting use case! It would indeed be awesome if any new team member can just run an npm command to set everything up!

To set everything up I think we need to do the following:

• Install the CLI
• Provision a credential (I'll go into more detail about this below).
• Get access to the secrets

Installation

If we add SecretHub installation via npm, we will be able to do the first step.

Provision a Credential

This relates a bit to the conversation we've had here: #297. In order to run SecretHub commands, the CLI should have access to a credential. You can see this credential as the "login" of an account. The credential is used both to authenticate to the SecretHub servers and for the encryption of your secrets.

Now there's several ways to get your hands on a credential:

• Run secrethub signup, which creates a credential in a file on your machine: ~/.secrethub/credential.
• Go to the procedure described here to create an additional credential for your personal account, to be used on another device. You would use this for example if you want to use SecretHub both on your laptop and a PC.
• Create a service account with service init, which outputs a key similar to the one that's created on signup. This credential authenticates the service account and has access to the secrets the service account is given access to. You can pass this credential to the SecretHub CLI by setting the SECRETHUB_CREDENTIAL environment variable or by creating a ~/.secrethub/credential file (for example, on a VM).
• For services that run on AWS, you can use AWS service accounts, which use an AWS IAM role and AWS KMS key instead of a key credential.

For your use case, I think we could use secrethub init in the npm command that sets everything up. It will prompt with a choice whether you want to sign up for a new command or use a backup code to initialize an existing account on this device. I believe this covers the local setup with a personal account.

Now for the CI setup, you could provision a SECRETHUB_CREDENTIAL environment variable using your CIs environment variable or if your CI runners are on AWS you'd use the SECRETHUB_IDENTITY_PROVIDER=aws environment variable.

Now, to be able to always run this secrethub init command regardless of whether you are in CI or on a local machine and regardless of whether there's already a credential provisioned, I suggest to add a flag to secrethub init which skips the setup if it already detects a credential. Then it will prompt teammates who still need to signup, while for teammates who have already done so it will immediately run your script.

In that case your npm command could look something like this: npm install && secrethub init --ignore-existing && secrethub run -- ./my-script.sh

Get Access to the Secrets

Now, one last remaining challenge is that if the new teammate signs up with the secrethub init, they have a new account, but they don't have access to the secrets they need yet. An admin would have to invite them to the workspace first and then give them acces to the secrets they need.

I can imagine a process where the new teammate can request access, after which an admin can approve that request so that they can proceed. In that case we could add an additional SecretHub command to your npm command which checks if the current account has access to the secrets it needs and requests access if not so. Then the request for access would be included in the single npm command a new teammate would have to run to get started with SecretHub.

I'll think about this a bit more and discuss in our team to see if/how this could work and how we can make the onboarding process as smooth as possible. If there's any information you can share on how you envision the onboarding process, that's really welcome!