DEV Community: DigitalOnUs

How to install Boundary on Ubuntu in 3 CLI commands

🦄N B🛡 — Fri, 20 Nov 2020 00:35:53 +0000

Press ctrl+alt+t to open a Terminal Emulator window in Ubuntu.

Then you can copy or type this in to install Boundary on Ubuntu Linux in a terminal:

curl -fsSL https://apt.releases.hashicorp.com/gpg | sudo apt-key add -
sudo apt-add-repository "deb [arch=amd64] https://apt.releases.hashicorp.com $(lsb_release -cs) main"
sudo apt-get update && sudo apt-get install boundary
boundary -h

To install, that is all.

But here's an example of running it, so you can see what your output should look like:

 * keychain 2.8.5 ~ http://www.funtoo.org
 * Waiting 5 seconds for lock...
 * Found existing ssh-agent: 4199
 * Known ssh key: /home/nb/.ssh/id_rsa

~$ curl -fsSL https://apt.releases.hashicorp.com/gpg | sudo apt-key add -
[sudo] password for norbert: 
OK
~$ sudo apt-add-repository "deb [arch=amd64] 
https://apt.releases.hashicorp.com $(lsb_release -cs) main"
Hit:1 
http://security.ubuntu.com/ubuntu focal-security/universe amd64 DEP-11 Metadata [56.6 kB]                                                                                                                  
Get:45 http://security.ubuntu.com/ubuntu focal-security/universe amd64 c-n-f Metadata [9,364 B]                                                                                                                   
Fetched 5,693 kB in 7s (792 kB/s)                                                                                                                                                                                 
Reading package lists... Done
~$ sudo apt-get update && sudo apt-get install boundary                                                                                                                       
Hit:4 https://apt.releases.hashicorp.com focal InRelease                                                                                                                            
Hit:5 http://us.archive.ubuntu.com/ubuntu focal InRelease                                               
Hit:6 http://security.ubuntu.com/ubuntu focal-security InRelease
Hit:7 http://us.archive.ubuntu.com/ubuntu focal-updates InRelease
Reading package lists... Done
Reading package lists... Done
Building dependency tree       
Reading state information... Done
The following NEW packages will be installed:
  boundary
0 upgraded, 1 newly installed, 0 to remove and 45 not upgraded.
Need to get 21.2 MB of archives.
After this operation, 48.9 MB of additional disk space will be used.
Get:1 https://apt.releases.hashicorp.com focal/main amd64 boundary amd64 0.1.2 [21.2 MB]
Fetched 21.2 MB in 4s (5,534 kB/s)   
Selecting previously unselected package boundary.
(Reading database ... 280569 files and directories currently installed.)
Preparing to unpack .../boundary_0.1.2_amd64.deb ...
Unpacking boundary (0.1.2) ...
Setting up boundary (0.1.2) ...
~$ echo $PATH | grep boundary
~1$ boundary -h
Usage: boundary <command> [args]

Commands:
    accounts           Manage Boundary accounts
    auth-methods       Manage Boundary auth methods
    auth-tokens        Manage Boundary auth tokens
    authenticate       Authenticate the Boundary command-line client
    config             Manage resources related to Boundary's local configuration
    connect            Connect to a target through a Boundary worker
    database           Manage Boundary's database
    dev                Start a Boundary dev environment
    groups             Manage Boundary groups
    host-catalogs      Manage Boundary host catalogs
    host-sets          Manage Boundary host sets
    hosts              Manage Boundary hosts
    roles              Manage Boundary roles
    scopes             Manage Boundary scopes
    server             Start a Boundary server
    sessions           Manage Boundary sessions
    targets            Manage Boundary targets
    users              Manage Boundary users
~$

Terraform Semantic Versioning as a Communication Tool

🦄N B🛡 — Thu, 19 Nov 2020 23:54:49 +0000

Communication from Shared Services

Although moving to a Cloud Operating model and self-service means a far greater degree of ownership of infrastructure by internal customers, these still need to rely on teams of specialists to maintain the platforms, libraries, modules, etc. that those consumers of internal services, well, consume.

One of the best ways for these specialists to communicate ideas to the wider org, beyond the usual meetings, workshops, and presentations, is code, specifically, versioning of code.

In Terraform Enterprise, this communication can take the form of versioning re-usable modules in an internal module registry.

External re-usable modules, like the Vault module, should have strict version pinning, and internal modules, to facilitate faster feedback loops and better communication with SRE, should have looser version pinning.

Here's an example policy that you can set:

Hi everyone at Rupture AgCorp IT,

We would like you all to make sure that you're pinning external Terraform Modules to their Minor version numbers, in accordance with Semantic Versioning (https://semver.org)
But for internal modules, because changes to these are much more directly relevant to compliance and business changes, we now require you to have looser version pinning, to major versions only.
This may cause issues, but they're issues we want to find out about, and handle, sooner rather than later.
It's part of the way that we can make sure that our efforts to improve our internal services are meeting your needs, and an even better feedback mechanism than the conversations you are all so gracious to have with us on a regular basis.
If you have any questions about this policy, or you think it's bunk, we're happy to discuss it as part of our portion of the Rupture AgCorp IT all-hands on Friday, or in person if you happen to drop by our desks.

But make sure everyone in the SRE group knows how to properly do Semantic Versioning, to avoid unwanted changes!

You need to do this because if someone in your core services team marks a change as a bug fix or a security patch that they should have marked as a minor or major version change, this will betray the expectations you've set with the consumers of your service. And people will give up, and all but the adventurous will just avoid adopting new versions at all.

For modules maintained within your organization, a version range strategy may be appropriate if a semantic versioning methodology is used consistently or if there is a well-defined release process that avoids unwanted updates.
--https://www.terraform.io/docs/configuration/modules.html#module-versions

Here are two example use cases:

Use Case 1: Legacy Terraform Versions

If you want to support Legacy Terraform versions, you can make a major version change reflect the new version of Terraform, e.g. Terraform 0.13.x would be supported by version 3.x.x of your module, and Terraform 0.12.x would be supported by version 2.x.x.

Use Case 2: Modules that "Wrap" External Modules

For instance, if you have a Module that adds some company specific context or standard resources to another module, like the AKS module, and you keep making updates each month, you do not want your internal projects and Terraform code for your SaaS or IaaS footprint to have versions pinned to the patch version. If the Terraform modules for your internal systems have their dependencies from the HashiCorp registry, like HashiCorp's Vault module, pinned to the security patch version, or minor version, well, OK. Maybe it's needed.

But if they're pinning your internally developed modules in your internal module registry to the patch version, it means you're missing out on a great chance to have productive conversations with the people who would consume your code about what they need and what they don't want.

It means that if you make an important change or necessary improvement in something they're not an expert in, they'll never know!

By the way, I haven't written this out of some kind of academic consideration for potential future issues.

This is a real solution to a real problem that organizations even more sophisticated than my own have run into. And I recommend that if you use Terraform and have shared services, you give it serious consideration.

Cohesion and Coupling for Secrets Management in CI/CD Work Flows

🦄N B🛡 — Mon, 11 May 2020 21:59:09 +0000

TL;DR: If you couple your some other deployment process to your Secrets Management, then you would have to redeploy for new creds. And that's bad.

There are a few "tight couplings" to avoid for Secrets Management:

Coupling to Infrastructure as Code (IaC)
Coupling to Configuration as Code (CaC)
Coupling to Application Deployment (CI/CD)

The test is, if I need to do an emergency revocation, do I have to wait for any of the above to complete?

For example, if you happen to be using git2consul for secrets management*, used in one of the above 3 systems, is the only way to update secrets, then you have to wait for a deployment for one of the above to complete. If the lack of those credentials is what's causing the problem in the first place, or the build happens to be broken at the same time as the emergency revocation occurs, you'd be in trouble.

A kinder, gentler way to decouple these work flows from Secrets Management? You could ensure that Consul could be edited directly for emergency. While still having a git2consul pipeline for the configs.

If you are generating database creds, and giving them to the application, that isn’t dynamic any longer as the application can not generate them but now receives them.

As long as git2consul isn't the only way to revoke / re-issue creds, I think that makes a lot of sense.

*If you have HashiCorp Vault available, it may be better to consider Vault for this, especially since Vault works with consul-template, or better yet envconsul or Vault Agent.

IAM vs PIM vs PAM vs HashiCorp Vault vs Skub in 20 seconds

🦄N B🛡 — Fri, 06 Mar 2020 04:01:50 +0000

Here's the answer in 10 seconds of video (2:03 to 2:13): https://youtu.be/cVYSc2d6Gco?t=123

But, because that's not long enough for a "real" blog post, I'll ramble on a bit more.

The big difference is machine identity vs human identity. And Dynamic Secrets Management vs Password/Privileged Access Management.

In a couple of sales conversations I've come across this question:

"What's the difference between Vault Enterprise and Traditional Privilege Access Management?"

Those of us who call ourselves Vault Nerds should all have a quick answer to this, because it's a high level question involving addressable markets for Services companies, and HashiCorp's product placement.

And here's a 5 minute talk by the HashiCorp founders about the difference between Identity and Access Management (IAM) and Privileged Access Management (PAM): https://youtu.be/x4Wf2W3Wl4w?t=117

Again, that link will jump you to the most important 10 seconds of video.

Anyway, now that I've told you where they're different, where's the overlap?

Why isn't there one tool or platform capable of handling both?

Well, perhaps changing direction from the clear distinctions set by Armon, HashiCorp Vault has feature-creeped further into the PIM game: https://www.vaultproject.io/use-cases/identity-based-access/

HashiCorp Vault's still not directly competing with the likes of Thycotic, CyberArk, or CA PAM.

And I wrote up an example of where a platform for "brokering" machine identities can also cover one PAM use case, namely SSH access to a sensitive machine: https://dev.to/digitalonus/vault-pim-2bp6

Privileged Identity Management (PIM) with HashiCorp Vault SSH Certificates

🦄N B🛡 — Sat, 22 Feb 2020 00:13:53 +0000

Vault's product managers and the HashiCorp founders have, in the past, established a fairly clear difference in the target market and solutions between traditional Privileged Access Management, Secrets Management, and Data Protection.

Privileged Access Management or Privileged Identity Management, as a use case or solution, refers to delegation of access to human operators, e.g. when a Kubernetes administrator needs to temporarily get access to an Azure account to review logs.

The Secrets Management use case needs a system to broker access among various systems and the platforms on which they run, e.g. when a Kubernetes Pod needs to access an S3 service.

Last but, in my view, most important, the Data Protection use case needs a way to set and enforce policy for limiting access to data, typically using cryptography via encryption, or even Encryption as a Service.

Some examples of cases where HashiCorp representatives have shied away from HashiCorp replacing PAM:

Vault Identity Design Goals (Note that LDAP Sync is not on the table): https://www.hashicorp.com/resources/vault-identity-system

Vault vs Traditional PAM tools: https://www.hashicorp.com/resources/difference-between-vault-and-traditional-pam

That said, HashiCorp has recently begun to pay more attention to Vault's potential to meet a few of the needs of PAM and PIM systems.

The website vaultproject.io just added PIM as a first class use case, next to Secrets Management and Data Protection: https://www.vaultproject.io/use-cases/identity-based-access

I'd like to discuss a common PIM scenario, and how developers can, with relative simplicity adapt a system like Vault to accomplish this.

Example scenario: I need a developer, named Pedro, to use a read-only user on a host OS whose SSH server trusts an SSH Certificate Authority in Vault.

Pedro logs in to the Vault GUI or CLI via SSO, and his policy gets him a 15-minute SSH certificate from the Signed SSH Certificate Secrets Engine.

Now Pedro can use that fresh 15-minute SSH certificate to log in as the read-only user.

NOTE: We can also create a user, and give Vault an SSH key for that user, to control single use authentications to servers. Vault would then log every authentication to its audit log. The process is slightly different from this, as it does require the SSH server on the host OS to talk to Vault as part of the SSH server's login flow. The SSH server would ask Vault if Pedro's login is still valid.

sequenceDiagram
    Admin ->> Vault: Set up SSH Certificate Secrets Engine Role
    Admin ->> Vault: Create Vault Policy which gives access to the above
    Admin ->> Vault: Associate Pedro's AD group with that Vault Policy.
    Admin ->> Ansible: Give Public Key from Vault SSH Certificate Secrets Engine to Ansible
    Ansible ->> RHEL OS: Add pedro user w/limited permissions
    Ansible ->> RHEL OS: Add Public Key from Vault SSH Certificate Secrets Engine Role to SSH Server
    Pedro ->> Vault: Log in with AD credentials
    Vault ->> AD: Get Credential validity and memberships
    Vault ->> Pedro: Vault Token
    Varun ->> Vault: Request SSH Cert using Token
    Vault ->> Pedro: ✓ SSH Cert for pedro user✓ 
    Pedro ->> Vault: Request DB credentials
    Vault ->> Pedro: ❌Permission Denied❌
    Pedro ->> RHEL OS: ssh pedro@RHELOS
    RHEL OS ->> Pedro: ✓ SSH connection✓ 
    Pedro ->> RHEL OS: ls
    Pedro ->> RHEL OS: scp pedro@RHELOS:/home/varun/applog .
    Pedro ->> RHEL OS: systemctl stop consul
    RHEL OS ->> Pedro: ❌Permission Denied❌

Note:

Vault has some other specific PIM features.

Active Directory Secret Check-In/Check-Out: In the Active Directory secrets engine, users or applications can check out a service account for use, and its password will be rotated when it's checked back in.

Dealing with Vault Leases via Accessors

🦄N B🛡 — Mon, 23 Sep 2019 21:35:34 +0000

Often, when administering Vault Enterprise, after its deployment, you'll need to configure it.

Much of the work after designing and planning is configuring Vault Enterprise via its API, or a wrapper of the API.

However, there come times, especially when troubleshooting or automating something, when an admin of Vault Enterprise has to manage the state within Vault, itself, rather than just the configuration.

This is especially true if there is a problem, like potential undesired access or application misbehavior.

What if you want to, as part of an investigation, see all of the currently valid access tokens, Azure Creds, or Database credentials that were created on a specific day?

I'll show you a script that will do this for you. Before we do that, though, we'll download a binary file to set up a "dummy" Vault to test on. You don't have to install anything, or write any configuration files.

For some background, I recommend reading about Vault Leases & the leasing "hierarchy" that Vault uses before we go further:

https://www.vaultproject.io/guides/identity/lease/

The documentation might be a bit confusing, but hopefully using it over the course of this guide will make things more clear.

Download Vault

We'll download the binary for HashiCorp Vault, because we can use it to run an easy Vault server:

https://www.vaultproject.io/downloads.html

After you have downloaded and extracted the binary file, open a Terminal window.

If You're on a Mac, Open a Bash Terminal

Open your Applications folder, then Utilities and double-click on Terminal, or press Command + spacebar to launch Spotlight, then type "Terminal", and double-click on the search result. You'll see a small window with a white background open o your desktop.

If you're on a Windows OS, Open a Shell Terminal

Open the Run dialog by holding the Windows key, and pressing R once. Then, enter cmd. When you press the Enter key, after entering cmd, you will see a black window with white text.

In your shell terminal that you just opened, use the cd command, along with the dir or ls commands, to navigate to where you downloaded Vault.

Run a Vault Server

Enter the following in the terminal when you have navigated your terminal to the folder in which you have downloaded and extracted Vault:

./vault server -dev -dev-root-token-id=root

You should see some output, from Vault, but you will not be able to enter more commands in this terminal.

To keep entering more commands, open another terminal, and navigate to the same folder in which you had downloaded and extracted Vault.

Connect to Vault

Mac: export VAULT_TOKEN=root
export VAULT_ADDR=http://127.0.0.1:8200
./vault status

The last command, the one with status, should show the status of your Vault. That shows that you can connect to it.

Download the script

git clone https://github.com/v6/delete_old_tokens
cd delete_old_tokens

Run the script

(This part might not work on Windows, but please don't let me stop you from converting the code to PowerShell or the like.)

./list_accessor_issue_time.sh | grep 2019-09-13

If you wanted to search for a different day, say, September 20, 2019, you would run the following, instead:

./list_accessor_issue_time.sh | grep 2019-09-20