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

minikube
type: Control Plane
host: Running
kubelet: Running
apiserver: Running
kubeconfig: Configured

Kubernetes is now set up.

Start a pod that represents a production workload a developer may need to view.
```
$ kubectl run nginx --image=nginx
pod/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 cautious
Starting 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                online
Account                       username (Plan: Free)
Update                        update available (version 3.0.5, Ctrl-U to update)
Version                       3.1.1
Region                        United States (us)
Latency                       32.791235ms
Web Interface                 http://127.0.0.1:4040
Forwarding                    http://d12b-34-567-89-10.ngrok.io -> 127.0.0.1:8001

Connections                   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-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 variables:

   $ export 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: 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 cautious
Starting 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.cloud
VAULT_ADDR=https://vault-cluster-exampe-012034567.06f0568a.z1.hashicorp.cloud:8200
VAULT_TOKEN=hvs.CAESIPA-K6F9TfY5Vm2nfObyzYum-peHhXPuYzX_BsybIKJMGicKImh2cy4wVXN4NWpyN3A4NUJ
VAULT_NAMESPACE=admin
KUBE_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 authenticate
Please 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_TOKEN
WARNING! The VAULT_TOKEN environment variable is set! The value of this
variable will take precedence; if this is unwanted please unset VAULT_TOKEN or
update its value accordingly.

Success! You are now authenticated. The token information displayed below
is 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.EXamPl3t7782QvHbHatL2f56i98VpKePzgqvHGicKImh2cy55bXZyMUVseWNZa00yem9pM3NuaHppRnQuOXpoQ0UQ9gE
token_accessor       tzwWshH6PwGHIFWq1dCCN2Xz.9zhCE
token_duration       5h54m30s
token_renewable      false
token_policies       ["default" "hcp-root"]
identity_policies    []
policies             ["default" "hcp-root"]

Verify connectivity to Kubernetes.

$ kubectl config view
apiVersion: v1
clusters:
- 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: minikube
contexts:
- 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: minikube
current-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