Connect to Kubernetes using Boundary lab setup

18min
|
Vault
Boundary

Deployment

In this tutorial you will take on the role of the operations team to deploy Boundary, Vault, and Kubernetes.

Prerequisites

This tutorial requires you to have completed the Connect to Kubernetes using Boundary introduction tutorial.

Deploy Kubernetes

(Persona: operations)

minikube is a CLI tool that provisions and manages the lifecycle of single-node Kubernetes cluster locally on your system.

Deploy a Kubernetes cluser using minikube.

Open a new terminal session.
Create a new working directory in your home directory called boundary-kubernetes to complete the lab exercises. Execute all commands from this working directory unless otherwise specified.
```
$ mkdir ~/boundary-kubernetes && cd ~/boundary-kubernetes/
```

Start a Kubernetes cluster.

$ minikube start 😄  minikube v1.25.2 on Darwin 12.3✨  Automatically selected the docker driver. Other choices: hyperkit, virtualbox, ssh👍  Starting control plane node minikube in cluster minikube🚜  Pulling base image ...🔥  Creating docker container (CPUs=2, Memory=8100MB) ...🐳  Preparing Kubernetes v1.23.3 on Docker 20.10.12 ...    ▪ kubelet.housekeeping-interval=5m    ▪ Generating certificates and keys ...    ▪ Booting up control plane ...    ▪ Configuring RBAC rules ...🔎  Verifying Kubernetes components...    ▪ Using image gcr.io/k8s-minikube/storage-provisioner:v5🌟  Enabled addons: storage-provisioner🏄  Done! kubectl is now configured to use "minikube" cluster and "default" namespace by default

The initialization process takes several minutes as it retrieves any necessary dependencies and executes various container images.

Verify the status of the Minikube cluster.

$ minikube status minikubetype: Control Planehost: Runningkubelet: Runningapiserver: Runningkubeconfig: Configured

Kubernetes is now set up.

Start a pod that represents a production workload a developer may need to view.
```
$ kubectl run nginx --image=nginxpod/nginx created
```

Deploy Boundary

(Persona: operations)

HashiCorp Boundary is an identity-aware proxy aimed at simplifying and securing least-privileged access to cloud infrastructure.

In this workflow you will test integrating Kubernetes with Boundary's dev mode.

Note

As of version 4.13.0 of Docker, you need to enable Allow the default Docker socket to be used in the Advanced settings section to run Boundary in dev mode.

Open a new terminal window, and start Boundary in dev mode:

$ boundary dev==> Boundary server configuration:         [Controller] AEAD Key Bytes: cXte2+fkVq/mnQ/VKO3cOL0bYQZKqJsQhWgPLvX9VsY=          [Recovery] AEAD Key Bytes: XGcczs8FJ7lIwd8PQJaP34go/ILiPIeMs+7anHkK+vE=       [Worker-Auth] AEAD Key Bytes: Y9A1Gw4Ja+IJbFtuGTSXLIw3L+aEPcwEpN+/lRqvWIQ=               [Recovery] AEAD Type: aes-gcm                   [Root] AEAD Type: aes-gcm            [Worker-Auth] AEAD Type: aes-gcm                                Cgo: disabled     Controller Public Cluster Addr: 127.0.0.1:9201             Dev Database Container: bold_heisenberg                   Dev Database Url: postgres://postgres:password@localhost:55001/boundary?sslmode=disable         Generated Admin Login Name: admin           Generated Admin Password: password          Generated Host Catalog Id: hcst_1234567890                  Generated Host Id: hst_1234567890              Generated Host Set Id: hsst_1234567890      Generated Oidc Auth Method Id: amoidc_1234567890             Generated Org Scope Id: o_1234567890  Generated Password Auth Method Id: ampw_1234567890         Generated Project Scope Id: p_1234567890                Generated Target Id: ttcp_1234567890  Generated Unprivileged Login Name: user    Generated Unprivileged Password: password                         Listener 1: tcp (addr: "127.0.0.1:9200", cors_allowed_headers: "[]", cors_allowed_origins: "[*]", cors_enabled: "true", max_request_duration: "1m30s", purpose: "api")                         Listener 2: tcp (addr: "127.0.0.1:9201", max_request_duration: "1m30s", purpose: "cluster")                         Listener 3: tcp (addr: "127.0.0.1:9203", max_request_duration: "1m30s", purpose: "ops")                         Listener 4: tcp (addr: "127.0.0.1:9202", max_request_duration: "1m30s", purpose: "proxy")                          Log Level: info                              Mlock: supported: false, enabled: false                            Version: Boundary v0.8.0                        Version Sha: 9b48dbc2fd4f9a9f0bda4ca68488590f681dbd9e+CHANGES           Worker Public Proxy Addr: 127.0.0.1:9202 ==> Boundary server started! Log data will stream in below: ... snip ...

Dev mode starts Boundary to listen on port 9200 and with a pre-configured administrative user named admin and a password of password. You will use the admin username and password to authenticate with Boundary.

Return to the terminal you started Kubernetes in and set the BOUNDARY_ADDR environment variable.
```
$ export BOUNDARY_ADDR=http://127.0.0.1:9200
```
Boundary is now set up.

Deploy Vault

(Persona: operations)

Vault is an identity-based secrets and encryption management system. Vault can generate secrets on-demand for some systems, such as AWS, and Kubernetes.

Select the appropriate tab to deploy an HCP Vault Dedicated cluster or deploy a Vault in dev mode.

Launch the HCP Portal and login.
From the Overview page, click Vault in the left navigation menu.
From the Vault overview click Create cluster under the Start from scratch section.
Select your preferred cloud provider.
Click the Vault tier pull down menu and select Development.
Click the Cluster size pull down menu and select Extra Small.
Under the Network section, accept or edit the Network ID, Region selection, and CIDR block for the HVN.
Leave Cluster accessibility set to Public.
Security consideration
All new development tier Vault Dedicated clusters are configured with public access enabled by default. This means clients can connect from anywhere. For production tiers (starter, standard, and plus) private access will be enabled by default. This means you can only connect from a transit gateway or peered VPC (AWS) or VNet (Azure).
Under the Basics section, accept or edit the default Cluster ID (vault-cluster).
Under Templates, select Start from scratch.
Click Create cluster.
Wait for the cluster to initialize before proceeding.
Under Quick actions, click Public Cluster URL.
Return to the terminal you started Kubernetes in and set the VAULT_ADDR environment variable to the copied URL.
```
$ export VAULT_ADDR=<public_cluster_URL>
```
Return to the Overview page and click Generate token.
Within a few moments a new token will be generated.
Copy the Admin Token.
Return to the terminal you started Kubernetes in and set the VAULT_TOKEN environment variable to the copied token.
```
$ export VAULT_TOKEN=<admin_token>
```
Set the VAULT_NAMESPACE environment variable to admin.
```
$ export VAULT_NAMESPACE=admin
```

Open a new terminal window, and start a proxy to expose the Kubernetes API.

$ kubectl proxy --disable-filter=true Request filter disabled, your proxy is vulnerable to XSRF attacks, please be cautiousStarting to serve on 127.0.0.1:8001

Leave this terminal open with the proxy running.

Open a new terminal window, and start ngrok and create a tunnel to the proxy listening on port 8001.

Warning

ngrok is used to expose the Kubernetes API to Vault Dedicated. Using --scheme=http exposes the API without encryption to avoid TLS certificate errors.

For production workloads, use a private peering or transit gateway connection with trusted certificates.

$ ngrok http --scheme=http 127.0.0.1:8001

Example output:

ngrok                                                                                                                                                              (Ctrl+C to quit)Session Status                onlineAccount                       username (Plan: Free)Update                        update available (version 3.0.5, Ctrl-U to update)Version                       3.1.1Region                        United States (us)Latency                       32.791235msWeb Interface                 http://127.0.0.1:4040Forwarding                    http://d12b-34-567-89-10.ngrok.io -> 127.0.0.1:8001Connections                   ttl     opn     rt1     rt5     p50     p90                              0       0       0.00    0.00    0.00    0.00

Leave this terminal open with ngrok running.

Copy the ngrok forwarding address.
Return to the terminal you started Kubernetes in and set an environment variable for the ngrok forwarding address.
```
$ export KUBE_API_URL=<actual-address-from-ngrok>
```
Vault Dedicated is now set up.

Learn the current terminal window open.

In a new terminal, start Vault in dev mode.

$ vault server -dev -dev-root-token-id=root ==> Vault server configuration:             Api Address: http://127.0.0.1:8200                     Cgo: disabled         Cluster Address: https://127.0.0.1:8201            Go Version: go1.19.1            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.13.0-dev1, built 2022-09-26T14:39:49Z            Version Sha: 2a7c3f2f76e6fd6a7f8622ea68d82bcf9dcf9686 ==> Vault server started! Log data will stream in below: # ...snip... WARNING! dev mode is enabled! In this mode, Vault runs entirely in-memoryand starts unsealed with a single unseal key. The root token is alreadyauthenticated to the CLI, so you can immediately begin using Vault. You may need to set the following environment variables:    $ export VAULT_ADDR='http://127.0.0.1:8200' The unseal key and root token are displayed below in case you want toseal/unseal the Vault or re-authenticate. Unseal Key: PLV0OXO9VmF5VB8qAnq4pQIGzWkzzYypRNcDtrhSSgU=Root Token: root Development mode should NOT be used in production installations!

Dev mode starts Vault to listen on port 8200 and uses the -dev-root-token-id parameter to set the root token to root.

Return to the terminal you started Kubernetes in and set the VAULT_ADDR environment variable.
```
$ export VAULT_ADDR='http://127.0.0.1:8200'
```
Set the VAULT_TOKEN environment variable.
```
$ export VAULT_TOKEN=root
```

Open a new terminal window, and start a proxy to expose the Kubernetes API.

$ kubectl proxy --disable-filter=true Request filter disabled, your proxy is vulnerable to XSRF attacks, please be cautiousStarting to serve on 127.0.0.1:8001

Leave this terminal open with the proxy running.

Return to the terminal you started Kubernetes in and set an environment variable for the Kubernetes API URL.
```
$ export KUBE_API_URL=http://127.0.0.1:8001
```

Vault is now set up.

Validate lab setup

The tutorials in this series use environment variables to simplify the provided commands.

Verify all necessary environment variables are set.

$ printenv | grep 'VAULT_\|BOUNDARY_\|KUBE_'BOUNDARY_ADDR=https://6a6eade6-example.boundary.hashicorp.cloudVAULT_ADDR=https://vault-cluster-exampe-012034567.06f0568a.z1.hashicorp.cloud:8200VAULT_TOKEN=hvs.CAESIPA-K6F9TfY5Vm2nfObyzYum-peHhXPuYzX_BsybIKJMGicKImh2cy4wVXN4NWpyN3A4NUJVAULT_NAMESPACE=adminKUBE_API_URL=http://d12b-34-567-89-10.ngrok.io

If you are missing any of the environment variables, go back and verify each product is running and set the required variables.

HCP Vault Dedicated

VAULT_NAMESPACE is only required when using Vault Dedicated and will not be present when following the Vault Dev mode workflow.

Verify connectivity by authenticating to Boundary. Enter the admin username and password when prompted.

$ boundary authenticatePlease enter the login name (it will be hidden):Please enter the password (it will be hidden): Authentication information:  Account ID:      acctpw_NgTnYJHTls  Auth Method ID:  ampw_PqQpz2sqvx  Expiration Time: Wed, 19 Jul 2023 09:52:02 EDT  User ID:         u_09ja9DkXo3 The token was successfully stored in the chosen keyring and is not displayed here.

Verify connectivity to Vault.

$ vault login token=$VAULT_TOKENWARNING! The VAULT_TOKEN environment variable is set! The value of thisvariable will take precedence; if this is unwanted please unset VAULT_TOKEN orupdate its value accordingly. Success! You are now authenticated. The token information displayed belowis already stored in the token helper. You do NOT need to run "vault login"again. Future Vault requests will automatically use this token. Key                  Value---                  -----token                hvs.EXamPl3t7782QvHbHatL2f56i98VpKePzgqvHGicKImh2cy55bXZyMUVseWNZa00yem9pM3NuaHppRnQuOXpoQ0UQ9gEtoken_accessor       tzwWshH6PwGHIFWq1dCCN2Xz.9zhCEtoken_duration       5h54m30stoken_renewable      falsetoken_policies       ["default" "hcp-root"]identity_policies    []policies             ["default" "hcp-root"]

Verify connectivity to Kubernetes.

$ kubectl config viewapiVersion: v1clusters:- cluster:    certificate-authority: /Users/username/.minikube/ca.crt    extensions:    - extension:        last-update: Wed, 12 Jul 2023 10:04:18 EDT        provider: minikube.sigs.k8s.io        version: v1.30.1      name: cluster_info    server: https://127.0.0.1:63060  name: minikubecontexts:- context:    cluster: minikube    extensions:    - extension:        last-update: Wed, 12 Jul 2023 10:04:18 EDT        provider: minikube.sigs.k8s.io        version: v1.30.1      name: context_info    namespace: default    user: minikube  name: minikubecurrent-context: minikube...snip...

A local minikube cluster will be listed under contexts.

Next steps

Boundary, Vault, and Kubernetes have been deployed and are ready to be configured.

In the Connect to Kubernetes using Boundary configuration tutorial, you will configure Kubernetes, configure Vault for Kubernetes, and configure Boundary to broker credentials from Vault to the Kubernetes cluster.

Introduction

Configure Boundary, Vault, and Kubernetes