{"id":19893629,"url":"https://github.com/cameronsenese/oke-hashicorp-vault-tutorial","last_synced_at":"2026-05-14T03:33:08.112Z","repository":{"id":170275772,"uuid":"607009576","full_name":"cameronsenese/oke-hashicorp-vault-tutorial","owner":"cameronsenese","description":"A guide to deploying HashiCorp Vault to Oracle Container Engine for Kubernetes (OKE). Vault is deployed in HA mode with the Kubernetes auth method configured. Note: This project is a mirror of the upstream GitLab project developed and maintained by Cameron Senese.","archived":false,"fork":false,"pushed_at":"2023-02-27T05:48:07.000Z","size":110,"stargazers_count":0,"open_issues_count":0,"forks_count":0,"subscribers_count":2,"default_branch":"master","last_synced_at":"2025-03-01T05:28:16.789Z","etag":null,"topics":["golang","hashicorp-vault","kubernetes","oke"],"latest_commit_sha":null,"homepage":"https://gitlab.com/byteQualia/oke-hashicorp-vault-tutorial","language":null,"has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"apache-2.0","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/cameronsenese.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":null,"funding":null,"license":"LICENSE","code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null}},"created_at":"2023-02-27T05:46:26.000Z","updated_at":"2023-02-27T05:49:42.000Z","dependencies_parsed_at":null,"dependency_job_id":"18f29da1-19de-4079-b8fc-138febb5ab56","html_url":"https://github.com/cameronsenese/oke-hashicorp-vault-tutorial","commit_stats":null,"previous_names":["cameronsenese/oke-hashicorp-vault-tutorial"],"tags_count":0,"template":false,"template_full_name":null,"purl":"pkg:github/cameronsenese/oke-hashicorp-vault-tutorial","repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/cameronsenese%2Foke-hashicorp-vault-tutorial","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/cameronsenese%2Foke-hashicorp-vault-tutorial/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/cameronsenese%2Foke-hashicorp-vault-tutorial/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/cameronsenese%2Foke-hashicorp-vault-tutorial/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/cameronsenese","download_url":"https://codeload.github.com/cameronsenese/oke-hashicorp-vault-tutorial/tar.gz/refs/heads/master","sbom_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/cameronsenese%2Foke-hashicorp-vault-tutorial/sbom","scorecard":null,"host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":286080680,"owners_count":33009479,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2026-05-13T13:14:54.681Z","status":"online","status_checked_at":"2026-05-14T02:00:06.663Z","response_time":57,"last_error":null,"robots_txt_status":"success","robots_txt_updated_at":"2025-07-24T06:49:26.215Z","robots_txt_url":"https://github.com/robots.txt","online":true,"can_crawl_api":true,"host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":["golang","hashicorp-vault","kubernetes","oke"],"created_at":"2024-11-12T18:30:14.946Z","updated_at":"2026-05-14T03:33:08.096Z","avatar_url":"https://github.com/cameronsenese.png","language":null,"funding_links":[],"categories":[],"sub_categories":[],"readme":"[vault]:[https://www.vaultproject.io/]\n[oci]:[https://cloud.oracle.com/en_US/cloud-infrastructure]\n[oke]:[https://cloud.oracle.com/containers/kubernetes-engine]\n[oci-signup]:[https://cloud.oracle.com/tryit]\n[kubectl]:[https://kubernetes.io/docs/tasks/tools/install-kubectl/]\n\n# Running Hashicorp Vault on [Oracle OKE][oke] (Container Engine for Kubernetes)\n\n## Introduction\nWelcome to our introduction to [Vault][vault]! In this work instruction, we'll show you how to get up and running with Vault on OKE - Oracle's managed Kubernetes service running on Oracle Cloud Infrastructure ([OCI][oci]).\n\nFirst we will introduce you to Hashicorp Vault, a comprehensive tool for securely managing secrets. A secret is anything that you want to tightly control access to, such as API keys, passwords, or certificates. Vault provides a unified interface to any secret, while providing important features such as an API driven framework delivering tight access control, version control, and detailed audit log.\n\nThen we'll take you through a Vault deployment scenario on [Oracle Container Engine for Kubernetes (OKE)][oke], whereby Vault will be integrated with the OKE cluster control plane using the Vault Kubernetes auth method. The Kubernetes auth method can be used facilitate authentication with Vault by using a Kubernetes Service Account Token. This method of authentication leverages native Kubernetes identity and access management, and makes it easy to introduce a Vault token into a Kubernetes Pod.\n\n## About [Vault][vault]\n\nSecret management is one of the core use cases for Vault. Vault enables organisations to secure, store and tightly control access to tokens, passwords, certificates, encryption keys for protecting secrets and other sensitive data using a UI, CLI, or HTTP API. Many organisations have credentials hard coded in source code, littered throughout configuration files and configuration management tools, and stored in plaintext in version control, wikis, and shared volumes. Vault provides a central place to store these credentials, ensuring they are encrypted, access is audit logged, and exposed only to authorized clients.\n\nVault provides a wide array of features across the secrets management, data protecton, identity-based access, collaboration \u0026 operations, and governance and compliance.\n\nVault tightly controls access to secrets and encryption keys by authenticating against trusted sources of identity such as Active Directory, LDAP, Kubernetes, and cloud platforms. Vault enables fine grained authorization of which users and applications are permitted access to secrets and keys.\n\n## Tutorial Overview\n\nLet’s consider an example of how we can:\n\n- Deploy Vault to our OKE cluster in a highly available, fault tolerant configuration\n- Provide our applications deployed to OKE with a simple mechanism to authenticate with Vault using their respective Kubernetes service account tokens\n\n![alt text](images/vault-deployment-scenario-v0.01.png \"Vault on OKE deployment topology\")\n\nThe Vault deployment scenario illustration describes the solution architecture implemented through this work instruction:\n\n - OKE Kubernetes cluster\n   - etcd and Vault Kubernetes operators\n   - Vault cluster\n     - Vault configured to use Kubernetes auth method\n     - Vault Key/Value (KV) store `secret/testapp`\n     - Vault role 'testapp' associated with the Kubernetes service account 'testapp' in the 'default' namespace\n     - Vault policy 'testapp-kv-crud' associated with 'testapp' role (providing CRUD access to the `secret/testapp` KV store)\n   - etcd cluster serving as persistent storage tier for the Vault cluster\n   - Test application authenticated to vault (via Kubernetes auth) using the 'testapp' service account\n   - Test application creating and reading secrets from the Vault `secret/testapp` KV store\n\nBoth the etcd and Vault clusters will be created by their respective Kubernetes operators.\nThe Vault operator deploys and manages Vault clusters on Kubernetes. Vault instances created by the Vault operator are highly available and support automatic failover and upgrade. For each Vault cluster, the Vault operator will also create an etcd cluster for the storage backend.\n\n_Note: For more information about Kubernetes operators and the Operator Framework, follow [this link](https://coreos.com/blog/introducing-operator-framework)._\n\nHigh level outline of the steps that will be followed:\n\n1. Deploy the Vault \u0026 etcd operators\n2. Deploy the Vault \u0026 etcd clusters\n3. Configure Vault Kubernetes auth\n4. Create the Vault Key/Value (KV) store \u0026 associated policy for the test application\n5. Deploy the test application and authenticate to Vault using Kubernetes auth\n6. Create and read secrets from the KV store\n\n### Prerequisites\n - You will need to have deployed your OKE Kubernetes cluster prior to commencing implementation of the deployment scenario. Follow the link to [this tutorial](https://www.oracle.com/webfolder/technetwork/tutorials/obe/oci/oke-full/index.html) for guidance on the process.\n - Create a 'kube config' authentication artefact. This will be used later in the tutorial to connect to the OKE cluster. Follow the link to [this tutorial](https://www.oracle.com/webfolder/technetwork/tutorials/obe/oci/oke-full/index.html#DownloadthekubeconfigFilefortheCluster) for guidance on the process.\n - Install the Vault CLI on the host from which you will be following this work instruction. Follow the link to [this tutorial](https://learn.hashicorp.com/vault/getting-started/install) for guidance on the process.\n\n#### Clone the 'oke-hashicorp-vault-tutorial' git repository\nClone the oke-hashicorp-vault-tutorial repository:\n\n``` bash\ngit clone https://github.com/oracle/cloudnative/security/oke-hashicorp-vault-tutorial.git\n```\n\nCommands from this point forward will assume that you are in the `../oke-hashicorp-vault-tutorial/` directory.\n\n## Deploying Vault\n\nThis section deals with deploying Vault to the OKE cluster.\n\n### Set up RBAC for etcd \u0026 Vault operators\n\nAs RBAC is enabled in our OKE custer, we need to implement RBAC configuration for the Kubernetes operators.\nThe Vault operator works in conjunction with the etcd operator to setup a Vault cluster. To do this both the etcd and Vault operators need RBAC permissions to access necessary resources.\n\nFor simplicity, this example binds a Role to the 'default' service account in the 'default' namespace.\n*Note: For production usage you should consider a specific service account to bind the Role to.*\n\n1. Create the Role and RoleBinding from the RBAC manifest:\n\n``` bash\n$ kubectl -n default create -f kubernetes/vault/operator-rbac.yaml\n```\n\n### Deploy the etcd operator\n\nThe Vault operator utilises the etcd operator to deploy an etcd cluster to be used as the storage backend for each Vault Cluster provisioned.\nThe following will implement the etcd operator:\n\n``` bash\n# Create the etcd operator Custom Resource Definitions (CRD)\n$ kubectl -n default create -f kubernetes/vault/etcd-crd.yaml\n\n# Deploy the etcd operator\n$ kubectl -n default create -f kubernetes/vault/etcd-operator-deployment.yaml\n```\n\n### Deploy the Vault operator\n\nThe following will implement the Vault operator:\n\n``` bash\n# Create the Vault operator Custom Resource Definitions (CRD)\n$ kubectl -n default create -f kubernetes/vault/vault-crd.yaml\n\n# Deploy the Vault operator\n$ kubectl -n default create -f kubernetes/vault/vault-operator-deployment.yaml\n```\n\n### Deploy a Vault cluster\n\nA Vault cluster can be deployed by creating a VaultService Custom Resource (CR). For each Vault cluster the Vault operator will also create an etcd cluster as the storage backend.\n\nThe following will create a Vault CR that deploys a 2 node Vault cluster named 'example' in high availablilty (HA) mode:\n\n``` bash\n$ kubectl -n default create -f kubernetes/vault/vault-example-cluster.yaml\n```\n\nVault will now be running in the OKE cluster. This can be validated as follows:\n\n```\n$ kubectl -n default get pods\n\nNAME                              READY     STATUS    RESTARTS   AGE\netcd-operator-779446c7d8-6j74d    3/3       Running   0          2m\nexample-668f9f8f7d-5vl5z          1/2       Running   0          11s\nexample-668f9f8f7d-mgsdp          1/2       Running   0          11s\nexample-etcd-knqw5gbchb           1/1       Running   0          46s\nexample-etcd-lp4bjddqkh           1/1       Running   0          1m\nexample-etcd-x9mnhjmz24           1/1       Running   0          30s\nvault-operator-7dc8b55b4d-5kzqb   1/1       Running   0          1m\n```\n\nThe return data should be similar to the above:\n - the 'etcd-operator-' and 'vault-operator-' Pods are running\n - the 'example-' etcd and Vault pods are also running\n\nWe can check the VaultService Custom Resource status as follows:\n\n```\n$ kubectl -n default get vault example -o yaml\n\napiVersion: vault.security.coreos.com/v1alpha1\nkind: VaultService\nmetadata:\n  creationTimestamp: 2019-02-13T10:10:34Z\n  generation: 1\n  name: example\n  namespace: default\n  resourceVersion: \"12019\"\n  selfLink: /apis/vault.security.coreos.com/v1alpha1/namespaces/default/vaultservices/example\n  uid: 9a0cd50c-2f77-11e9-83d5-0a580aed1c35\nspec:\n  TLS:\n    static:\n      clientSecret: example-default-vault-client-tls\n      serverSecret: example-default-vault-server-tls\n  baseImage: quay.io/coreos/vault\n  configMapName: \"\"\n  nodes: 2\n  version: 0.9.1-0\nstatus:\n  clientPort: 8200\n  initialized: false\n  phase: Running\n  serviceName: example\n  updatedNodes:\n  - example-668f9f8f7d-5vl5z\n  - example-668f9f8f7d-mgsdp\n  vaultStatus:\n    active: \"\"\n    sealed:\n    - example-668f9f8f7d-5vl5z\n    - example-668f9f8f7d-mgsdp\n    standby: null\n```\n\nThe return data should be similar to the above:\n  - the Vault cluster is currently running, uninitialized, and in a sealed state.\n\n## Configuring Vault\n\nNow that we have our Vault cluster up and running on OKE, this next section deals with unsealing, initializing, and configuring the Vault cluster.\n\n### Configure accounts and RBAC\n\nLet's create a dedicated service account 'vault-tokenreview' for Vault Kubernetes auth, and then provide the serviceaccount with the rights to perform delegated authentication and authorization checks (`system:auth-delegator` role):\n\n``` bash\n$ kubectl -n default create serviceaccount vault-tokenreview\n$ kubectl -n default create -f kubernetes/vault/vault-tokenreview-rbac.yaml\n```\n\n### Connect to Vault\n\nIn order to connect to Vault, we will first configure port forwarding between the local machine and the first sealed Vault node. In a terminal window issue the following command:\n\n``` bash\n$ kubectl -n default get vault example -o jsonpath='{.status.vaultStatus.sealed[0]}' | xargs -0 -I {} kubectl -n default port-forward {} 8200\n```\n\nNext, open a new terminal and export the following environment for the Vault CLI client:\n\n``` bash\n$ export VAULT_ADDR='https://localhost:8200'\n$ export VAULT_SKIP_VERIFY=\"true\"\n```\n\nVerify that the Vault server is accessible using the `vault status` command:\n\n``` bash\n$ vault status\n\nError checking seal status: Error making API request.\n\nURL: GET https://localhost:8200/v1/sys/seal-status\nCode: 400. Errors:\n\n* server is not yet initialized\n```\n\nThe response confirms that the Vault CLI is successfully interacting with the Vault server. However, the output indicates that the Vault server is not initialized.\n\n### Initialize the Vault cluster\n\nWhen you first setup a Vault server, you need to begin by initializing it.\nInitialization is the process configuring the Vault. This only happens once when the server is started against a new backend that has never been used with Vault before. When running in HA mode, this happens once per cluster, not per instance.\nDuring initialization the encryption keys are generated, unseal keys are created, and the initial root token is setup.\n\nTo initialize Vault use the Vault CLI command `vault operator init`. This is an unauthenticated request, so it only works on brand new Vaults with no data:\n\n```\n$ vault operator init\n\nUnseal Key 1: Hmw5YKMZyKj1JM2t0pxEthgGGU+5PKjOV1KKLZw0Qhcy\nUnseal Key 2: FThbg/t4rznUnk/OtTahIIQRlqsQJp2SXvcA0neeAoCl\nUnseal Key 3: 2qYJcMQ9x0trtg4bc/216d0xljwkJn6iWwfYXXcrgHhx\nUnseal Key 4: UlbYndrXB6kbGti8LzhLDvj+IWRRyWhBjw0mgxT1uaMb\nUnseal Key 5: ivzgZ6m6GK4s4T9wDymZK9fyVnkcQ/Z/YbSZuA6LJ9fh\n\nInitial Root Token: 645655db-3aec-36e1-2cb9-c8eb2396c163\n\nVault initialized with 5 key shares and a key threshold of 3. Please securely\ndistribute the key shares printed above. When the Vault is re-sealed,\nrestarted, or stopped, you must supply at least 3 of these keys to unseal it\nbefore it can start servicing requests.\n\nVault does not store the generated master key. Without at least 3 key to\nreconstruct the master key, Vault will remain permanently sealed!\n\nIt is possible to generate new unseal keys, provided you have a quorum of\nexisting unseal keys shares. See \"vault operator rekey\" for more information.\n```\n\nInitialization outputs two essential pieces of information:\n - the unseal keys\n - the initial root token\n\nThis is the only time that all of this data is known by Vault, and also the only time that the unseal keys should ever be so close together.\nFor the purpose of this work instruction - save all of these keys somewhere handy, and continue.\n\n### Unseal the Vault and authenticate\n\nEvery initialized Vault server starts in the sealed state. From the configuration, Vault can access the physical storage, but it can't read any of it because it doesn't know how to decrypt it. The process of enabling Vault to decrypt the data is known as unsealing the Vault.\n\nUnsealing has to happen every time Vault starts. It can be done via the API and via the command line. To unseal the Vault, you must have the threshold number of unseal keys. In the output above, notice that the 'key threshold' is 3. This means that to unseal the Vault, you need 3 of the 5 keys that were generated.\n\nBegin unsealing the Vault by issuing the following command:\n\n```\n$ vault operator unseal\n\nUnseal Key (will be hidden):\nKey                Value\n---                -----\nSeal Type          shamir\nInitialized        false\nSealed             true\nTotal Shares       5\nThreshold          3\nUnseal Progress    1/3\nUnseal Nonce       bbf64780-c7ef-d920-02e7-4363906f668f\nVersion            0.9.1\nHA Enabled         true\n```\n\nAfter pasting in a valid key and confirming, you'll see that the Vault is still sealed, but progress is made.\nContinue with `vault operator unseal` to complete unsealing the Vault. To unseal the vault you must use three different keys. When the value for 'Sealed' changes to false, the Vault is unsealed.\n\nFinally, authenticate as the initial root token (it was included in the output with the unseal keys):\n\n```\n$ vault login 645655db-3aec-36e1-2cb9-c8eb2396c163\n\nSuccess! You are now authenticated. The token information displayed below\nis already stored in the token helper. You do NOT need to run \"vault login\"\nagain. Future Vault requests will automatically use this token.\n\nKey                  Value\n---                  -----\ntoken                faa21577-f039-07f2-aafb-373e3978765b\ntoken_accessor       e4398d13-013d-046c-b4ee-251ffd95f805\ntoken_duration       ∞\ntoken_renewable      false\ntoken_policies       [\"root\"]\nidentity_policies    []\npolicies             [\"root\"]\n```\n\nBefore moving on to configure the Kubernetes auth method, let's create a Vault policy called 'testapp-kv-crud' which we will enable for Kubernetes auth in the following steps. The policy will be applied to a KV store (`secret/testapp/*`) where our test secrets will reside.\n\n``` bash\n# Create a policy file, testapp-kv-crud.hcl\n$ tee testapp-kv-crud.hcl \u003c\u003cEOF\n  path \"secret/testapp/*\" {\n       capabilities = [\"create\", \"read\", \"update\", \"delete\", \"list\"]\n}\nEOF\n\n# Create a policy named testapp-kv-crud\n$ vault policy write testapp-kv-crud testapp-kv-crud.hcl\n```\n\n### Enable the Kubernetes auth method\n\nNow we enable the Kubernetes auth method in Vault at the default path:\n\n```\n$ vault auth enable kubernetes\n```\n\nNext, let's export the token for the 'vault-tokenreview' service account, which will be used in the Vault Kubernetes auth configuration:\n\n``` bash\n# Set VAULT_SA_NAME to the service account created previously\n$ export VAULT_SA_NAME=$(kubectl get sa vault-tokenreview -o jsonpath=\"{.secrets[*]['name']}\")\n\n# Set SA_JWT_TOKEN value to the service account JWT used to access the TokenReview API\n$ export SA_JWT_TOKEN=$(kubectl get secret $VAULT_SA_NAME -o jsonpath=\"{.data.token}\" | base64 --decode; echo)\n\n# Set SA_CA_CRT to the PEM encoded CA cert used to talk to the Kubernetes API\n$ export SA_CA_CRT=$(kubectl get secret $VAULT_SA_NAME -o jsonpath=\"{.data['ca\\.crt']}\" | base64 --decode; echo)\n```\n\nNow we configure Vault with the Kubernetes master server URL, token reviewer JWT, and certificate authority data for communicating with the OKE control plane:\n\n``` bash\n$ vault write auth/kubernetes/config \\\n      token_reviewer_jwt=\"$SA_JWT_TOKEN\" \\\n      kubernetes_host=\"https://kubernetes.default.svc:443\" \\\n      kubernetes_ca_cert=\"$SA_CA_CRT\"\n```\n\nAnd finally, create a Kubernetes service account \u0026 Vault role named 'testapp' mapping the Kubernetes service account to the Vault policy testapp-kv-crud and setting the default Vault token TTL to 4h:\n\n``` bash\n$ kubectl -n default create serviceaccount testapp\n$ vault write auth/kubernetes/role/testapp \\\n      bound_service_account_names=testapp \\\n      bound_service_account_namespaces=default \\\n      policies=testapp-kv-crud \\\n      ttl=4h\n```\n\nThat's it! Your Vault deployment is running and configured for Kubernetes auth.\nPods running in the context of the 'testapp' Kubernetes service account will be able to authenticate to Vault using the Kubernetes service account token, which will provide access to Vault resources associated with the 'testapp-kv-crud' policy.\nPer the previous configuration steps - implemeted policy file 'testapp-kv-crud.hcl' grants CRUD access to the Vault KV secrets engine at `/secret/testapp/*`.\n\n## Testing the Vault Kubernetes auth method\n\nIn order to explore the Kubernetes auth method on OKE, the following creates a Kubernetes deployment 'testapp' which will be authenticated to Vault using Kubernetes auth, then walks through the creation and reading of secrets from a Vault KV store.\n\nFirst, create and connect to Pod with a container running alpine:3.7 image:\n\n``` bash\nkubectl run testapp --rm -i --tty --serviceaccount=testapp --image alpine:3.7\n```\n\nOnce you are inside the container, install the Vault CLI:\n\n```\n/# wget https://releases.hashicorp.com/vault/1.0.2/vault_1.0.2_linux_amd64.zip\n/# unzip vault_1.0.2_linux_amd64.zip -d /usr/local/bin/\n```\n\n*Note: The following interactions can also be performed directly using the Vault API via cURL.*\n\nSet the `VAULT_ADDR` environment variable to point to the running Vault where you configured Kubernetes auth method, and test the connection:\n\n```\n/# export VAULT_ADDR=https://example.default.svc:8200\n/# export VAULT_SKIP_VERIFY=\"true\"\n/# vault status\n\nKey             Value\n---             -----\nSeal Type       shamir\nInitialized     false\nSealed          false\nTotal Shares    5\nThreshold       3\nVersion         0.9.1\nCluster Name    vault-cluster-05b1e306\nCluster ID      9d8e752c-d60e-b467-c19c-1b61330baace\nHA Enabled      true\nHA Cluster      https://example.default.svc:8201\nHA Mode         active\n```\n\nSet `KUBE_TOKEN` to the service account token value (default/testapp):\n\n```\n/# export KUBE_TOKEN=$(cat /var/run/secrets/kubernetes.io/serviceaccount/token)\n/# echo $KUBE_TOKEN\n\neyJhbGciOiJSUzI1NiIsImtpZCI6IiJ9.eyJpc3MiOiJrdWJlcm5ldGVzL3NlcnZpY2VhY2NvdW50Iiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9uYW1lc3BhY2UiOiJkZWZhdWx0Iiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9zZWNyZXQubmFtZSI6InRlc3RhcHAtdG9rZW4tcjVwYnAiLCJrdWJlcm5ldGVzLmlvL3NlcnZpY2VhY2NvdW50L3NlcnZpY2UtYWNjb3VudC5uYW1lIjoidGVzdGFwcCIsImt1YmVybmV0ZXMuaW8vc2VydmljZWFjY291bnQvc2VydmljZS1hY2NvdW50LnVpZCI6IjI0MWU4ZWYxLTJmN2EtMTFlOS04M2Q1LTBhNTgwYWVkMWMzNSIsInN1YiI6InN5c3RlbTpzZXJ2aWNlYWNjb3VudDpkZWZhdWx0OnRlc3RhcHAifQ.eJvOr8wI-LwgV3uVugRQ0qR-5h3Ap59Ynf709DIQhL7AtLmS78oPGFq5cBI1biSv-DD4wjXHzTVbR1B-v2kQz87Hxz2I5R8-oO4FFPCYM3_8yI00DfsCIN34G1i7pLayHxHFpxkPiDAGHnodlHLboFhVDGZ00eIK0KY_6XDI1Lrz1vc5RDnX8yB89mO5nxXNNjJq1Ae0-0fFBZ52hA1lQ4TJ1HNWs0-ctCAdczFcA6Z96qvHO-HeHLSISjc9UHscbq--eZqXz64deFQWlCfhPnCitiZRBKCITcGiA5do_G_Uhu23kRya6-Z72P8IozBCJhmTLHp4AROgIIS26HpAUQ\n```\n\nNow authenticate to Vault using the 'testapp' service account token:\n\n```\n/# vault write auth/kubernetes/login role=testapp jwt=${KUBE_TOKEN}\n\nKey                                       Value\n---                                       -----\ntoken                                     cc74f359-6c2e-6061-e56e-07d616a63836\ntoken_accessor                            333984d4-b06c-5be9-3b64-55940797f19f\ntoken_duration                            4h\ntoken_renewable                           true\ntoken_policies                            []\nidentity_policies                         []\npolicies                                  [\"default\" \"testapp-kv-crud\"]\ntoken_meta_service_account_uid            241e8ef1-2f7a-11e9-83d5-0a580aed1c35\ntoken_meta_role                           testapp\ntoken_meta_service_account_name           testapp\ntoken_meta_service_account_namespace      default\ntoken_meta_service_account_secret_name    testapp-token-r5pbp\n```\n\nNotice from the return data that the Vault token is successfully generated, and the 'testapp-kv-crud' policy is associated with the token. The metadata reflects that its service account name ('token_meta_service_account_name') is testapp.\n\nLogin using the Vault token provided via the Kubernetes auth in the previous step:\n\n```\n/# vault login cc74f359-6c2e-6061-e56e-07d616a63836\n\nSuccess! You are now authenticated. The token information displayed below\nis already stored in the token helper. You do NOT need to run \"vault login\"\nagain. Future Vault requests will automatically use this token.\n\nKey                                       Value\n---                                       -----\ntoken                                     2fefa26c-06da-33b5-0e91-e91f8d81ae88\ntoken_accessor                            3e14e77a-498e-0089-33d4-d5ae96b4b93a\ntoken_duration                            3h57m18s\ntoken_renewable                           true\ntoken_policies                            [\"default\" \"testapp-kv-crud\"]\nidentity_policies                         []\npolicies                                  [\"default\" \"testapp-kv-crud\"]\ntoken_meta_role                           testapp\ntoken_meta_service_account_name           testapp\ntoken_meta_service_account_namespace      default\ntoken_meta_service_account_secret_name    testapp-token-r5pbp\ntoken_meta_service_account_uid            241e8ef1-2f7a-11e9-83d5-0a580aed1c35\n```\n\n### Create and retreive secret in the KV secret/testapp path\n\nThe Vault `write` command writes data to Vault at the given path. The data can be credentials, secrets, configuration, or arbitrary data. The specific behavior of this command is determined at the resource mounted at the path. Data is specified as \"key=value\" pairs.\n\nTo persist data in the KV secrets engine at the path `secret/testapp/*` to which we are delegated CRUD access:\n\n```\n/# vault write secret/testapp/foo value=bar\n\nKey              Value\n---              -----\ncreated_time     2018-12-21T06:01:26.972484174Z\ndeletion_time    n/a\ndestroyed        false\nversion          1\n```\n\nThe Vault `read` command reads data from Vault at the given path. This can be used to read secrets, generate dynamic credentials, get configuration details, and more.\n\nTo read back our secret foo at the path `secret/testapp/foo`:\n\n```\n/# vault read secret/testapp/foo\n\nKey                 Value\n---                 -----\nrefresh_interval    768h\nvalue               bar\n```\n\n## Conclusion\n\nIn our example deployment scenario we interact manually between our 'testapp' deployment and the Vault KV store for the purposes of demonstration. In a production deployment, it's possible to make the process of authenticating to Vault more automated by using the [Vault Agent](https://www.vaultproject.io/docs/agent/).\n\nVault Agent provides a number of different helper features, specifically addressing automatic authentication, secure delivery/storage of tokens, \u0026 lifecycle management of Vault tokens (renewal \u0026 re-authentication).\nHashicorp provide a [work instruction](https://learn.hashicorp.com/vault/developer/vault-agent-k8s#step-4-leverage-vault-agent-auto-auth) which describes the process for configuring a Kubernetes deployment which leverages Vault Agent to automatically authenticate with Vault via Kubernetes auth, and retrieve a client token.\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fcameronsenese%2Foke-hashicorp-vault-tutorial","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fcameronsenese%2Foke-hashicorp-vault-tutorial","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fcameronsenese%2Foke-hashicorp-vault-tutorial/lists"}