DEV Community: 🦄N B🛡

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.

Happy International Men's Day!

🦄N B🛡 — Thu, 19 Nov 2020 23:53:08 +0000

I invite you all to take some time today to celebrate the special men in your life and work.

For me, the most special man is my father.

((Note, that little guy isn't actually ripped. I can tell by the pixels.))

How do I Skip the Default Policy in Vault?

🦄N B🛡 — Tue, 17 Nov 2020 19:34:48 +0000

So here's something youze guyze ain't gonna know off the top of your balding pates...

When Vault set up with external identity provider like LDAP/OIDC/JWT/XYZ, if a user logging into Vault does not have a group definition that mapped to a policy, then it will be logging in as “default” policy

Is way to limit even the default policy, so that the domain user cannot even login and see the cubbyhole at all? Unless they are part of a group that have a policy mapped

Well, you can modify the default policy, of course.

But I suspect that's not gonna help most of you.

This flag in the API, token_no_default_policy, might help, at least for the JWT/OIDC auth method with its various providers: https://www.vaultproject.io/api-docs/auth/jwt#token_no_default_policy

And a quick quack of the ol' DDG shows that it seems they slapped this sucker on most of the other auth methods:

https://duckduckgo.com/?q=token_no_default_policy+site%3Avaultproject.io&t=h_&ia=web

So, there you go! If it works, you may express your gratitude for my generosity in the comments.

If it doesn't work, you may express your boundless rage for my imbecility in the comments.

If I know a Vault CLI command, how do I get its cURL Command?

🦄N B🛡 — Wed, 14 Oct 2020 01:05:24 +0000

If you have a command like vault auth enable oidc, how do you know its corresponding API call? Like this:

vault auth disable -output-curl-string oidc

Here's an example:

$ vault auth enable oidc
Success! Enabled oidc auth method at: oidc/

$ vault auth disable oidc
Success! Disabled the auth method (if it existed) at: oidc/

$ vault auth enable -output-curl-string oidc
curl -X POST -H "X-Vault-Request: true" -H "X-Vault-Token: $(vault print token)"
 -d '{"type":"oidc","description":"","config":{"options":null,"default_lease_ttl
":"0s","max_lease_ttl":"0s","force_no_cache":false},"local":false,"seal_wrap":fa
lse,"external_entropy_access":false,"options":null}' http://127.0.0.1:8200/v1/sy
s/auth/oidc

$ vault auth disable -output-curl-string oidc
curl -X DELETE -H "X-Vault-Request: true" -H "X-Vault-Token: $(vault print token
)" http://127.0.0.1:8200/v1/sys/auth/oidc

For more on the easy way to use the Vault API got get or generate "Secrets," I recommend this link:

https://www.slideshare.net/mitchp/vault-secrets-via-api-for-the-rest-of-us

Bash Functions for Vault

🦄N B🛡 — Wed, 14 Oct 2020 01:03:05 +0000

For those of us who've used Vault a lot, we all know and love the Vault CLI.

But, well, it has its quirks. If not outright shortcomings.

And if something isn't working in the CLI, my first instinct is to check the API, using a curl command from the Vault API Docs. But that takes a lot of typing.

Here's how to solve that:

Bash Aliases
Bash Functions

It's like you can build your own custom CLI commands. If the first thing that comes to your mind when you read that is, "Why. Why would anyone want that." You haven't experienced enough pain. Close this blog and come back to it later when you've lain awake at night haunted by WALs.

Anyway, back to the Bash Aliases and Bash Functions for Vault. I'll give a couple examples of each.

Bash Aliases for Vault

tknchk

## This alias gets you your token's permissions, and assumes you have the jq CLI utility installed
alias tknchk='curl -s --header "X-Vault-Namespace: $VAULT_NAMESPACE" --header "X-Vault-Token: $VAULT_TOKEN" "$VAULT_ADDR/v1/sys/internal/ui/resultant-acl | jq'

getVaultMounts

## This alias gets the mounts on the current Vault
alias getvaultmounts='curl -s --header "X-Vault-Namespace: $VAULT_NAMESPACE" --header "X-Vault-Token: $VAULT_TOKEN" "$VAULT_ADDR/v1/sys/mounts'

Bash Functions for Vault

getVaultToken

## Get the damn Vault Token without needing to show it on the screen or do the whole set +o history thing
export VAULT_TOKEN
function getVaultToken(){
    read -rsp "Enter the damn Vault Token:" entered_value
    export VAULT_TOKEN="$entered_value"
    echo ""

muhVault

function muhVault(){
echo "____   ____            .__   __    ___________.__              ._.
\   \ /   /____   __ __|  |_/  |_  \__    ___/|__| _____   ____| |
 \   Y   /\__  \ |  |  \  |\   __\   |    |   |  |/     \_/ __ \ |
  \     /  / __ \|  |  /  |_|  |     |    |   |  |  Y Y  \  ___/\|
   \___/  (____  /____/|____/__|     |____|   |__|__|_|  /\___  >_
               \/                                      \/     \/\/"

}

Well, there you go!

Which of these did you find useful? Got any of your own that you use?

HashiCorp Vault Enterprise and Azure Active Directory

🦄N B🛡 — Thu, 08 Oct 2020 15:42:58 +0000

If you're using AAD for authentication in other parts of your organization, there's a good chance you should be using it for Vault, too.

LDAP, compared to OIDC, is insecure. And don't even get me started about the potential problems at scale with good ol' userpass...

To do this, you'll need to make an App Registration for Vault Enterprise.

Then, you'll need to follow these instructions, but figure out how they work with Azure Active Directory instead of Auth0:

https://learn.hashicorp.com/tutorials/vault/oidc-auth?in=vault/auth-methods

(Guess which one is easier...)

But you have a few choices about what to do with that App Registration you make in Azure Active Directory.

Approach number 1: Use AAD's idea of App Roles.

AAD has an idea of "App Roles" in its App Registration manifests. These App Roles can be assigned to various groups, and provided as a "claim" in part of the JWT (JSON Web Token) in OIDC. Every time you want to add a new Azure AD "App Role," though, you have to edit the "Manifest" of the App Registration to add items to the JSON array labeled 'appRoles'. If you need to have an AAD Security Group with a different Vault Policy or set of Policies, you'll need add yet another Azure AD App Role, and a new Vault Auth Role in the Vault OIDC Auth Method for your Azure AD App Registration. Then, you add the AAD Security Group to your App Registration, and assign it the new AAD App Role you just made in your AAD App Registration.

Approach number 2: Use Vault Identity Groups

Skip the AAD App Roles, which have a limit of 1200 roles, and AAD App Roles require painful mutation of the "Manifest" by hand. Just use Vault Identity Groups instead. To each Vault Identity Group, you add an Identity Group Alias, and name that Identity Group Alias after the "Object Id" of the AAD Security Group that you want in Vault Enterprise. This means you still get to have AAD as an identification store and "source of truth" for authorization, where removal from or addition to AAD Security Groups controls authentication & authorization in Vault. But you also don't have to edit any JSON manifests.

Approach number 3: Use Vault Entities

A third approach, for admins of Vault Enterprise, would be to map various AAD user aliases to corresponding "entities" in Vault Enterprise's "Identity" Secrets Engine, then add those "entities" to the Vault Identity Groups that have various policies associated to them. I guess it is more of an onboarding scenario in which Vault manages much of the identification, and, because this is all done on a user-by-user basis, this entails no mapping of any given AAD Security Groups to Vault Identity Groups. It's a bit tricky, since Vault, at this point, is its own "source of truth" for permissions, and the only thing AAD is getting used for is to determine whether they have a valid AAD User.

JQ Recipes for HashiCorp Vault

🦄N B🛡 — Wed, 07 Oct 2020 22:48:50 +0000

This post will show some recipes for working with the jq utility in Bash to get data from HashiCorp Vault Enterprise via its ReST API.

You can install jq from here:

https://stedolan.github.io/jq

And if you don't have a "Bash" environment, you can get one from here: https://git-scm.com (make sure to select the "Git Bash" option when given the choice in the installation process)

If you're on Windows you might have some troubles or need to use some different name for jq-64.exe.

You also need to download and unzip Vault from https://vaultproject.io, and run it in a Git Bash like this:

$ cd ~/Downloads
$ echo 'alias vault="~/Downloads/vault.exe"' >> ~/.bash_profile ##(Only do this if you're on Windows)
$ source ~/.bash_profile ## Again, needed only if you're on Windows
$ ./vault server -dev -dev-root-token-id=s.JzcMzvFCAVHvxE4xusglvoHF

==> Vault server configuration:

             Api Address: http://127.0.0.1:8200
                     Cgo: disabled
         Cluster Address: https://127.0.0.1:8201
              Go Version: go1.14.7
              Listener 1: tcp (addr: "127.0.0.1:8200", cluster address: "127.0.0.1:8201", max_request_duration: "1m30s", max_request_size: "33554432", tls
: "disabled")
               Log Level: info
                   Mlock: supported: false, enabled: false
           Recovery Mode: false
                 Storage: inmem
                 Version: Vault v1.5.3
             Version Sha: 9fcd81405feb320390b9d71e15a691c3bc1daeef

WARNING! dev mode is enabled! In this mode, Vault runs entirely in-memory
and starts unsealed with a single unseal key. The root token is already
authenticated to the CLI, so you can immediately begin using Vault.

You may need to set the following environment variable:

PowerShell:
    $env:VAULT_ADDR="http://127.0.0.1:8200"
cmd.exe:
    set VAULT_ADDR=http://127.0.0.1:8200

The unseal key and root token are displayed below in case you want to
seal/unseal the Vault or re-authenticate.

Unseal Key: t/5BTQzZ5LbD0JIYkpQ9dY3fLEqZEMyena3aCh4+sWw=
Root Token: s.JzcMzvFCAVHvxE4xusglvoHF

Development mode should NOT be used in production installations!

==> Vault server started! Log data will stream in below:

2020-10-07T15:14:47.286-0700 [INFO]  proxy environment: http_proxy= https_proxy= no_proxy=
2020-10-07T15:14:47.289-0700 [WARN]  no `api_addr` value specified in config or in VAULT_API_ADDR; falling back to detection if possible, but this value s
hould be manually set
2020-10-07T15:14:47.327-0700 [INFO]  core: security barrier not initialized
2020-10-07T15:14:47.327-0700 [INFO]  core: security barrier initialized: stored=1 shares=1 threshold=1
2020-10-07T15:14:47.332-0700 [INFO]  core: post-unseal setup starting
2020-10-07T15:14:47.349-0700 [INFO]  core: loaded wrapping token key
2020-10-07T15:14:47.349-0700 [INFO]  core: successfully setup plugin catalog: plugin-directory=
2020-10-07T15:14:47.356-0700 [INFO]  core: no mounts; adding default mount table
2020-10-07T15:14:47.360-0700 [INFO]  core: successfully mounted backend: type=cubbyhole path=cubbyhole/
2020-10-07T15:14:47.363-0700 [INFO]  core: successfully mounted backend: type=system path=sys/
2020-10-07T15:14:47.365-0700 [INFO]  core: successfully mounted backend: type=identity path=identity/
2020-10-07T15:14:47.370-0700 [INFO]  core: successfully enabled credential backend: type=token path=token/
2020-10-07T15:14:47.370-0700 [INFO]  rollback: starting rollback manager
2020-10-07T15:14:47.370-0700 [INFO]  core: restoring leases
2020-10-07T15:14:47.376-0700 [INFO]  expiration: lease restore complete
2020-10-07T15:14:47.376-0700 [INFO]  identity: entities restored
2020-10-07T15:14:47.376-0700 [INFO]  identity: groups restored
2020-10-07T15:14:47.377-0700 [INFO]  core: post-unseal setup complete
2020-10-07T15:14:47.380-0700 [INFO]  core: root token generated
2020-10-07T15:14:47.380-0700 [INFO]  core: pre-seal teardown starting
2020-10-07T15:14:47.380-0700 [INFO]  rollback: stopping rollback manager
2020-10-07T15:14:47.380-0700 [INFO]  core: pre-seal teardown complete
2020-10-07T15:14:47.381-0700 [INFO]  core.cluster-listener.tcp: starting listener: listener_address=127.0.0.1:8201
2020-10-07T15:14:47.381-0700 [INFO]  core.cluster-listener: serving cluster requests: cluster_listen_address=127.0.0.1:8201
2020-10-07T15:14:47.381-0700 [INFO]  core: post-unseal setup starting
2020-10-07T15:14:47.381-0700 [INFO]  core: loaded wrapping token key
2020-10-07T15:14:47.381-0700 [INFO]  core: successfully setup plugin catalog: plugin-directory=
2020-10-07T15:14:47.382-0700 [INFO]  core: successfully mounted backend: type=system path=sys/
2020-10-07T15:14:47.383-0700 [INFO]  core: successfully mounted backend: type=identity path=identity/
2020-10-07T15:14:47.383-0700 [INFO]  core: successfully mounted backend: type=cubbyhole path=cubbyhole/
2020-10-07T15:14:47.384-0700 [INFO]  core: successfully enabled credential backend: type=token path=token/
2020-10-07T15:14:47.384-0700 [INFO]  rollback: starting rollback manager
2020-10-07T15:14:47.384-0700 [INFO]  core: restoring leases
2020-10-07T15:14:47.384-0700 [INFO]  identity: entities restored
2020-10-07T15:14:47.384-0700 [INFO]  expiration: lease restore complete
2020-10-07T15:14:47.384-0700 [INFO]  identity: groups restored
2020-10-07T15:14:47.384-0700 [INFO]  core: post-unseal setup complete
2020-10-07T15:14:47.384-0700 [INFO]  core: vault is unsealed
2020-10-07T15:14:47.401-0700 [INFO]  core: successful mount: namespace= path=secret/ type=kv
2020-10-07T15:14:47.411-0700 [INFO]  secrets.kv.kv_8bdaeac5: collecting keys to upgrade
2020-10-07T15:14:47.411-0700 [INFO]  secrets.kv.kv_8bdaeac5: done collecting keys: num_keys=1
2020-10-07T15:14:47.411-0700 [INFO]  secrets.kv.kv_8bdaeac5: upgrading keys finished

Leave Vault running in that terminal window, and open another one to run the following stuff in:

export VAULT_ADDR=http://127.0.0.1:8200
export VAULT_TOKEN=s.JzcMzvFCAVHvxE4xusglvoHF

Now, to prepare further, create some auth methods:

./vault auth enable kubernetes
./vault auth enable userpass
./vault auth enable okta
./vault auth enable aws

Example 1: Get a list of all of the Auth Methods that are of type `okta`

Shameless theft from this SO dude: https://stackoverflow.com/questions/18592173/select-objects-based-on-value-of-variable-in-object-using-jq/31911811#comment112920282_18608100

First, look at the response without jq:

curl --request GET --header "X-Vault-Token: $VAULT_TOKEN" --header "X-Vault-Namespace: $VAULT_NAMESPACE" $VAULT_ADDR/v1/sys/auth

Here's the output from that command:

$ curl --request GET --header "X-Vault-Token: $VAULT_TOKEN" --header "X-Vault-Namespace: $VAULT_NAMESPACE" $VAULT_ADDR/v1/sys/auth
{"kubernetes/":{"accessor":"auth_kubernetes_9bc9df5a","config":{"default_lease_t
tl":0,"force_no_cache":false,"max_lease_ttl":0,"token_type":"default-service"},"
description":"","external_entropy_access":false,"local":false,"options":null,"se
al_wrap":false,"type":"kubernetes","uuid":"72df2827-2ac1-1fb1-7d5a-c6262a4f5300"
},"token/":{"accessor":"auth_token_332e9370","config":{"default_lease_ttl":0,"fo
rce_no_cache":false,"max_lease_ttl":0,"token_type":"default-service"},"descripti
on":"token based credentials","external_entropy_access":false,"local":false,"opt
ions":null,"seal_wrap":false,"type":"token","uuid":"ba81c552-e8aa-9ba9-5243-0580
59545ccc"},"userpass/":{"accessor":"auth_userpass_1dd44d0b","config":{"default_l
ease_ttl":0,"force_no_cache":false,"max_lease_ttl":0,"token_type":"default-servi
ce"},"description":"","external_entropy_access":false,"local":false,"options":nu
ll,"seal_wrap":false,"type":"userpass","uuid":"e02a55d0-bd07-efeb-f5de-37fb5dcd5
84a"},"okta/":{"accessor":"auth_okta_fb869c57","config":{"default_lease_ttl":0,"
force_no_cache":false,"max_lease_ttl":0,"token_type":"default-service"},"descrip
tion":"","external_entropy_access":false,"local":false,"options":null,"seal_wrap
":false,"type":"okta","uuid":"1a445f3a-d302-ac6b-4508-def7a289894a"},"request_id
":"dc3dbab5-e001-498b-514c-05665baf09d2","lease_id":"","renewable":false,"lease_
duration":0,"data":{"kubernetes/":{"accessor":"auth_kubernetes_9bc9df5a","config
":{"default_lease_ttl":0,"force_no_cache":false,"max_lease_ttl":0,"token_type":"
default-service"},"description":"","external_entropy_access":false,"local":false
,"options":null,"seal_wrap":false,"type":"kubernetes","uuid":"72df2827-2ac1-1fb1
-7d5a-c6262a4f5300"},"okta/":{"accessor":"auth_okta_fb869c57","config":{"default
_lease_ttl":0,"force_no_cache":false,"max_lease_ttl":0,"token_type":"default-ser
vice"},"description":"","external_entropy_access":false,"local":false,"options":
null,"seal_wrap":false,"type":"okta","uuid":"1a445f3a-d302-ac6b-4508-def7a289894
a"},"token/":{"accessor":"auth_token_332e9370","config":{"default_lease_ttl":0,"
force_no_cache":false,"max_lease_ttl":0,"token_type":"default-service"},"descrip
tion":"token based credentials","external_entropy_access":false,"local":false,"o
ptions":null,"seal_wrap":false,"type":"token","uuid":"ba81c552-e8aa-9ba9-5243-05
8059545ccc"},"userpass/":{"accessor":"auth_userpass_1dd44d0b","config":{"default
_lease_ttl":0,"force_no_cache":false,"max_lease_ttl":0,"token_type":"default-ser
vice"},"description":"","external_entropy_access":false,"local":false,"options":
null,"seal_wrap":false,"type":"userpass","uuid":"e02a55d0-bd07-efeb-f5de-37fb5dc
d584a"}},"wrap_info":null,"warnings":null,"auth":null}

Pretty messy, right? Let's clean it up a bit:

curl --request GET --header "X-Vault-Token $VAULT_TOKEN" --header "X-Vault-Namespace $VAULT_NAMESPACE" $VAULT_ADDR/v1/sys/auth | jq

The above command will show the output in more of a structured format with indentation to indicate deeper levels of the object.

Here's the output from the above command:

$ curl --request GET --header "X-Vault-Token: $VAULT_TOKEN" --header "X-Vault-Namespace: $VAULT_NAMESPACE" $VAULT_ADDR/v1/sys/auth | jq
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100  2695    0  2695    0     0   105k      0 --:--:-- --:--:-- --:--:--  105k
{
  "token/": {
    "accessor": "auth_token_332e9370",
    "config": {
      "default_lease_ttl": 0,
      "force_no_cache": false,
      "max_lease_ttl": 0,
      "token_type": "default-service"
    },
    "description": "token based credentials",
    "external_entropy_access": false,
    "local": false,
    "options": null,
    "seal_wrap": false,
    "type": "token",
    "uuid": "ba81c552-e8aa-9ba9-5243-058059545ccc"
  },
  "userpass/": {
    "accessor": "auth_userpass_1dd44d0b",
    "config": {
      "default_lease_ttl": 0,
      "force_no_cache": false,
      "max_lease_ttl": 0,
      "token_type": "default-service"
    },
    "description": "",
    "external_entropy_access": false,
    "local": false,
    "options": null,
    "seal_wrap": false,
    "type": "userpass",
    "uuid": "e02a55d0-bd07-efeb-f5de-37fb5dcd584a"
  },
  "okta/": {
    "accessor": "auth_okta_fb869c57",
    "config": {
      "default_lease_ttl": 0,
      "force_no_cache": false,
      "max_lease_ttl": 0,
      "token_type": "default-service"
    },
    "description": "",
    "external_entropy_access": false,
    "local": false,
    "options": null,
    "seal_wrap": false,
    "type": "okta",
    "uuid": "1a445f3a-d302-ac6b-4508-def7a289894a"
  },
  "kubernetes/": {
    "accessor": "auth_kubernetes_9bc9df5a",
    "config": {
      "default_lease_ttl": 0,
      "force_no_cache": false,
      "max_lease_ttl": 0,
      "token_type": "default-service"
    },
    "description": "",
    "external_entropy_access": false,
    "local": false,
    "options": null,
    "seal_wrap": false,
    "type": "kubernetes",
    "uuid": "72df2827-2ac1-1fb1-7d5a-c6262a4f5300"
  },
  "request_id": "633adc4e-bd04-e579-58d4-34bde3dc91ee",
  "lease_id": "",
  "renewable": false,
  "lease_duration": 0,
  "data": {
    "kubernetes/": {
      "accessor": "auth_kubernetes_9bc9df5a",
      "config": {
        "default_lease_ttl": 0,
        "force_no_cache": false,
        "max_lease_ttl": 0,
        "token_type": "default-service"
      },
      "description": "",
      "external_entropy_access": false,
      "local": false,
      "options": null,
      "seal_wrap": false,
      "type": "kubernetes",
      "uuid": "72df2827-2ac1-1fb1-7d5a-c6262a4f5300"
    },
    "okta/": {
      "accessor": "auth_okta_fb869c57",
      "config": {
        "default_lease_ttl": 0,
        "force_no_cache": false,
        "max_lease_ttl": 0,
        "token_type": "default-service"
      },
      "description": "",
      "external_entropy_access": false,
      "local": false,
      "options": null,
      "seal_wrap": false,
      "type": "okta",
      "uuid": "1a445f3a-d302-ac6b-4508-def7a289894a"
    },
    "token/": {
      "accessor": "auth_token_332e9370",
      "config": {
        "default_lease_ttl": 0,
        "force_no_cache": false,
        "max_lease_ttl": 0,
        "token_type": "default-service"
      },
      "description": "token based credentials",
      "external_entropy_access": false,
      "local": false,
      "options": null,
      "seal_wrap": false,
      "type": "token",
      "uuid": "ba81c552-e8aa-9ba9-5243-058059545ccc"
    },
    "userpass/": {
      "accessor": "auth_userpass_1dd44d0b",
      "config": {
        "default_lease_ttl": 0,
        "force_no_cache": false,
        "max_lease_ttl": 0,
        "token_type": "default-service"
      },
      "description": "",
      "external_entropy_access": false,
      "local": false,
      "options": null,
      "seal_wrap": false,
      "type": "userpass",
      "uuid": "e02a55d0-bd07-efeb-f5de-37fb5dcd584a"
    }
  },
  "wrap_info": null,
  "warnings": null,
  "auth": null
}

Now, let's get all of the Auth Methods that are of type okta:

curl --request GET --header "X-Vault-Token: $VAULT_TOKEN" --header "X-Vault-Namespace: $VAULT_NAMESPACE" $VAULT_ADDR/v1/sys/auth | jq .data | jq 'to_entries[] | select(.value.type=="okta") | .key'

The first part gets you the contents of the "data" part of the response. The second part, with the 'to_entries[], gets you the data in a format where you can read out the key names separately. The | select(.value.type=="okta") part gets you the auth methods that have the value "okta" under the key type. The | .key' part gets you the key of the auth method, usually ending in a /.

Here's the output for my example (should just be "okta/"):

$ curl --request GET --header "X-Vault-Token: $VAULT_TOKEN" --header "X-Vault-Namespace: $VAULT_NAMESPACE" $VAULT_ADDR/v1/sys/auth | jq .data | jq 'to_entries[] | select(.value.type=="okta") | .key'
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100  2695    0  2695    0     0   125k      0 --:--:-- --:--:-- --:--:--  125k
"okta/"

Example 2: How to get an accessor based on a Bash variable:

export OKTAAUTH='okta/'

cat << EOF > jqparams.txt
."data"."${OKTAAUTH}/"."accessor"
EOF

curl --request GET --header "X-Vault-Token: $VAULT_TOKEN" --header "X-Vault-Namespace: $VAULT_NAMESPACE" $VAULT_ADDR/v1/sys/auth | jq -f jqparams.txt

Here's an example:

$ export OKTAAUTH='okta/'

$ cat << EOF > jqparams.txt
> ."data"."${OKTAAUTH}"."accessor"
> EOF

$ curl --request GET --header "X-Vault-Token: $VAULT_TOKEN" --header "X-Vault-Namespace: $VAULT_NAMESPACE" $VAULT_ADDR/v1/sys/auth | jq -f jqparams.txt
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100  2695    0  2695    0     0   125k      0 --:--:-- --:--:-- --:--:--  125k
"auth_okta_fb869c57"

$

Example 3: How to get an Accessor Without a Bash Variable

In this case, it's the same as Example 2, except that you needn't bother with a jqparams.txt file.

."data"."okta/"."accessor"

Vault Enterprise Service Glossary

🦄N B🛡 — Thu, 24 Sep 2020 02:28:38 +0000

Post installation of Vault Enterprise servers, clusters, storage backends, supporting Cloud Resources, and Load Balancers, there's still much to be done in the Vault API!

And much to be said. When documenting any of the many integrations of Vault with other services and systems, you could use the following glossary of terms:

Vault Enterprise Service - The overall Secrets Management service offered to your developers and other users, as implemented by Vault Enterprise (Or the open source version too). Example: "The Rupture Vault Enterprise Service" offered at secrets.internal.ruptureranch.co, supported by the skilled Vault SREs of Rupture Ranch Inc.

Vault Plugins - These augment Vault's core functionality beyond what the Vault Enterprise Binary can do. Each Vault Plugin enables a new "Vault Secrets Engine" or a new "Vault Auth Method." You install a Vault Plugin by putting the plugin's binary into a folder in the same system that the Vault Binary runs in, and configuring Vault to look for plugins inside that folder. This functionality can be restricted, but by default is available to all Vault Namespaces once installed. Example: The vault-btc plugin uses Vault to implement a Bitcoin wallet, and can be installed by copying one of its release binaries to the /etc/vault.d/plugins/ directory, and adding that /etc/vault.d/plugins/ directory to your vault.hcl configuration file.

Vault Namespace - A "Vault within a Vault" that can be used for delegation of authority, separation of duties, reducing the blast radius of a change, confidentiality levels, GPDR compliance, or self service. Example: The pci Vault Namespace is separate from the dbtest Vault Namespace, within the Vault Enterprise Service.

Vault Mount - At the top level of Vault, or at the top level of a Vault Namespace within Vault, this is an endpoint like a Secrets Engine or another namespace that can be enabled by the user.

Vault Secrets Engine - A type of "mount" at the top level of a Vault Namespace, which stores Secrets or generates them on behalf of the API Consumers of the Vault Enterprise Service. These either store "Static Secrets" from static secret paths or generate "Dynamic Secrets" from Secret Engine Roles, to be described later.

Vault API Consumers - Clients that make HTTP requests to the Vault Enterprise API. Example: A Python script running in an AWS lambda sending an HTTP request to a Vault Enterprise Service to generate a Dynamic Secret.

Vault Auth Method - An authentication method for Vault, at the root of the Vault, or within a Vault Namespace, preceded by /auth/. Example: A TLS Auth Method was enabled within the pci namespace at v1/pci/auth/cert.

Vault Auth Method Role - A Role, within an Authentication Method for Vault, against which a given Vault API Consumer or consumers may authenticate. These grant Vault Tokens tied to a set of one or more Vault ACL Policies.

Vault Secrets Engine Role - These are created within Secrets Engines, and will generate Dynamic Secrets on demand. Example: The vgdbx001 Vault Secrets Engine Role was created within the postgres02 Vault Secrets Engine within the pci Vault Namespace at v1/pci/postgres02/roles/vgdbx001.

Vault Tokens - Vault API Tokens used to authenticate HTTP Requests to Vault.

Vault ACL Policies - Lists of API paths or, within a Vault Namespace, relative API paths, each with another list of the operations allowed against the API endpoints that correspond to those API paths or relative API paths. Example: The pci-namespace-admin Vault ACL policy grants permission to do any operation against any of paths within the pci Vault Namespace.

Vault API Request - An HTTP request to the Vault Enterprise Service's ReST API. Typically includes the header X-Vault-Token, and the header X-Vault-Namespace.

Advanced Vault Identity Terms

This section has some more details on concepts related to the Vault Identity store. More details are in the documentation at vaultproject.io:

vaultproject.io: Vault Identity Concepts

Vault Identity Store - A system that keeps track of all of the Vault Clients.

Vault Entity - A Vault Entity is a given recognized client in Vault's client identity model, and may have multiple Vault Aliases associated with it.

Vault Aliases - Any of the various authentication leases from roles to which a given Vault Entity is associated.

Vault Entity Group - A Group of Vault Entities

Examples of Using the Terms

Here are some more examples stringing these together:

I enabled & configured an Auth Method, but I didn't add any Auth Method Roles in it yet!

In the dbtest Namespace, I made a API Request to make a new Auth Method Role in the aws Auth Method, and added the pci-readonly ACL Policy to that role.

We may have had higher load on the Vault Servers because we got so many Vault API Requests against our new Vault Secrets Engine Role in the PostGreSQL Vault Secrets Engine.

If you want to see all of the Secrets Engines in your dbtest/ Vault Namespace, you should list all of the Vault Mounts in dbtest/.

When writing documentation that's focused on people who do not have deep experience with Vault Enterprise, it may be wise to put the word "Vault" in front of the specific term, in case it may be confused with another system. For instance, saying Vault Namespace rather than just Namespace may help avoid confusion with a Kubernetes Namespace.

For any questions, or to add a term, send me a message!

I also want comments on this page using the above terms in ways that make sense.

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.

Is Telegram the Best in Class for Privacy? (TL;DR: Nope)

🦄N B🛡 — Sat, 11 Apr 2020 00:45:58 +0000

I do not typically recommend the Telegram application for private messaging, neither to technical neophytes nor to those of us more advanced in the ways of InfoSec.

Especially because any people who would be willing to get a more secure messaging application might as well get an app backed by more solid encryption & a UX with more secure defaults. Which Telegram is, well, not.

I have come across some reviews of Telegram's implementation. The Telegram creators "rolled their own" custom built encryption algorithm, and made some questionable choices in the process.

Chats are not encrypted by default.

Telegram developers can in overwhelming majority of cases read peoples' messages. And I have heard rumors, though I cannot confirm them, that some Telegram server operators have begun to exercise some minimal editorial prerogatives by monitoring and removal of content they deem objectionable. Perhaps there's a rationale for that, but "we find your message content objectionable" doesn't reassure me that my message content is private.

TLDR: Telegram's private chats are more secure than SMS, and have, by dint of hard work, earn the coveted "banned in Russia/Iran " stamp of approval. But Telegram's relatively good UI hides a relatively questionable underlying implementation.

It's not just me. Others are skeptical of Telegram's underlying security as well, especially in comparison to applications designed for the purpose of keeping message content private by default, like Signal Private Messenger or Keybase.

Source:
On the CCA (in)security of MTProto

Links that at least good for showing "I'm not the only grumpy troll out there who's skeptical of this BS.":
https://news.ycombinator.com/item?id=16795219
https://news.ycombinator.com/item?id=6913632
https://www.schneier.com/blog/archives/2016/06/comparing_messa.html

vault Error ... unsupported protocol scheme ""

🦄N B🛡 — Wed, 11 Mar 2020 01:19:04 +0000

I was brainless enough to get into this situation while using the Vault client binary:

unsupported protocol scheme ""

A better translation would be, "WTF my man, is this even a URI??"

It's probably because of a malformed URI or absent URI getting used in a web request by GoLang's HTTP thingy.

if !isHTTP {
        req.closeBody()
        return nil, &badStringError{"unsupported protocol scheme", scheme}
    }

Here's an example of what I did with it:

namespaccckler[micro-service-metadata-provider !?+]$ vault status
Error checking seal status: Get notsosecure/v1/sys/seal-status: unsupported protocol scheme ""
namespaccckler1[micro-service-metadata-provider !?+]$ export VAULT_ADDR=http://127.0.0.1:8200
namespaccckler[micro-service-metadata-provider !?+]$ vault status
Key             Value
---             -----
Seal Type       shamir
Initialized     true
Sealed          false
Total Shares    10
Threshold       4
Version         1.6.3+prem
Cluster Name    vault-cluster-c9387625
Cluster ID      0280f278-443a-210c-dcdd-c3dee0bd5f1d
HA Enabled      false
namespaccckler[micro-service-metadata-provider !?+]$

Anyone else run into this sort of bungling?

DEV Community: 🦄N B🛡

How to install Boundary on Ubuntu in 3 CLI commands

Terraform Semantic Versioning as a Communication Tool

Communication from Shared Services

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

Use Case 1: Legacy Terraform Versions

Use Case 2: Modules that "Wrap" External Modules

Further Reading:

Happy International Men's Day!

How do I Skip the Default Policy in Vault?

If I know a Vault CLI command, how do I get its cURL Command?

Bash Functions for Vault

Bash Aliases for Vault

Bash Functions for Vault

HashiCorp Vault Enterprise and Azure Active Directory

Approach number 1: Use AAD's idea of App Roles.

Approach number 2: Use Vault Identity Groups

Approach number 3: Use Vault Entities

JQ Recipes for HashiCorp Vault

Example 1: Get a list of all of the Auth Methods that are of type okta

Example 2: How to get an accessor based on a Bash variable:

Example 3: How to get an Accessor Without a Bash Variable

Vault Enterprise Service Glossary

Advanced Vault Identity Terms

Examples of Using the Terms

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

Is Telegram the Best in Class for Privacy? (TL;DR: Nope)

vault Error ... unsupported protocol scheme ""

Example 1: Get a list of all of the Auth Methods that are of type `okta`