move vault notes to a separate file

2 files changed, 80 insertions, 107 deletions

diff --git a/doc/run-identity/README.md b/doc/run-identity/README.md
index a83929d..d00bc5d 100644
--- a/doc/run-identity/README.md
+++ b/doc/run-identity/README.md
@@ -1,31 +1,53 @@
-We will be exploring the idea of Run Identity for TFC, and how it could be used
-to automate the authentication of Terraform providers at scale. While our work
-this quarter will determine the eventual solution, one direction that has been
-discussed would be to include a JWT with every run that includes the run's
-workspace and organization in its metadata.
+# Terraform Workload Identity - Product Spiel
 
-Our overarching goal though is to enable the Vault Provider to be programmatically
-configured to access a Workspace's secrets securely without the need to store
-and manage Vault credentials inside TFC. 
+> Credentials == #1 Customer Pain
 
-Reference Links:
+* operation concerns
+* risk
+* onboarding time
 
-* [PRD](https://docs.google.com/document/d/1IGSX1eSk6zQw1Fk0LUuJ9KgeEZgQoPg7126NfnQbL1M/edit#)
-* [GitHub Example](https://docs.github.com/en/actions/deployment/security-hardening-your-deployments/about-security-hardening-with-openid-connect#understanding-the-oidc-token)
-* [GitHub Configure Subject](https://docs.github.com/en/actions/deployment/security-hardening-your-deployments/about-security-hardening-with-openid-connect#configuring-the-subject-in-your-cloud-provider)
-* [GitLab example with Vault](https://docs.gitlab.com/ee/ci/examples/authenticating-with-hashicorp-vault/)
+1. But what about variable sets?
 
-Related Field Requests:
+* so much better than what we had
+* not much better of a risk story
+
+> "OIDC" == Trust
+
+* ecosystem building around standard
+* Just in time (JIT) access
+* Vault JWT Auth Method
+* AWS, GCP, and Azure support
+* Custom customer solutions
 
-* [Workspace Authentication (w/ Vault)](https://app.asana.com/0/1118351459439625/1141373083986005)
-* [Vault Provider Authentication in TFE](https://app.asana.com/0/950583539553838/1169207799468041)
-* [[TFE] Cloud Provider Authentication (w/ Vault)](https://app.asana.com/0/1118351459439625/1169212936201843)
+> We will enable power users and set the foundation for mass adoption
 
-To Learn:
+* JPMC, Snowflake and others will start using JWT immediately
+* AWS wants to base all authen for their service catalog products on JWTs
+* Azure is asking for it without knowing we are looking at it
+* Cross team buy-in on longer term plan
+* Bring JIT access to the masses
 
-* [X] the OIDC flows.
-* [X] the Vault API.
-* [X] the key material available to a Terraform run context.
+Acceptance Criteria:
+
+* JWT's are unique for each stage of a run including plan, apply and run tasks.
+* Generated during speculative plans and standard runs
+* Exposed as an environment variable in the terraform build environment.
+* Not stored to state unless practitioner specifically references it from Terraform.
+* Accessible on agent-based workloads including hooks
+* Given a TTL that corresponds to the system timeout on the current workload.
+* JWT metadata must include:
+  * id of the run
+  * workspace id of the run
+  * organization id of the run
+  * stage of the run. i.e. speculative plan, plan, apply, run.
+
+To think about:
+
+1. NTP syncronization to ensure time matches from client to server.
+1. X.509 certificate expiration management?
+1. Who is on the app-sec team? (Brian?)
+
+* [PRD](https://docs.google.com/document/d/1IGSX1eSk6zQw1Fk0LUuJ9KgeEZgQoPg7126NfnQbL1M/edit#)
 
 1. In cloud provider, create OIDC trust between cloud role and TFC Workspace.
 1. In run task, generate a token via OIDC Provider before apply step.
@@ -201,90 +223,4 @@ To Learn:
 7. TFC injects secrets into the `Run`. I don't know how. Config variables, maybe?
 8. The `Run` makes API calls to the cloud provider using the `AWS_ACCESS_KEY_ID` and`AWS_SECRET_KEY` env vars that were injected.
 
-# Vault
-
-Start the server:
-
-```bash
-$ vault server -dev
-```
-
-```bash
-モ vault export VAULT_ADDR=http://127.0.0.1:8200
-モ vault export VAULT_TOKEN=hvs.example
-モ vault kv put cubbyhole/rails session_secret=example
-Success! Data written to: cubbyhole/rails
-モ vault kv get cubbyhole/rails
-========= Data =========
-Key               Value
----               -----
-session_secret    example
-モ vault kv get -field=session_secret cubbyhole/rails
-example
-```
-
-To create a new namespace for secrets you need to provide a path prefix.
-
-```bash
-モ vault secrets enable -path=rails kv
-Success! Enabled the kv secrets engine at: rails/
-モ vault secrets list
-Path          Type         Accessor              Description
-----          ----         --------              -----------
-cubbyhole/    cubbyhole    cubbyhole_75d064e5    per-token private secret storage
-identity/     identity     identity_d11fdd33     identity store
-rails/        kv           kv_6ca5f254           n/a
-secret/       kv           kv_c50fa680           key/value secret storage
-sys/          system       system_5e571326       system endpoints used for control, policy and debugging
-```
-
-# Terraform Workload Identity - Product Spiel
-
-> Credentials == #1 Customer Pain
-
-* operation concerns
-* risk
-* onboarding time
-
-1. But what about variable sets?
-
-* so much better than what we had
-* not much better of a risk story
-
-> "OIDC" == Trust
-
-* ecosystem building around standard
-* Just in time (JIT) access
-* Vault JWT Auth Method
-* AWS, GCP, and Azure support
-* Custom customer solutions
-
-> We will enable power users and set the foundation for mass adoption
-
-* JPMC, Snowflake and others will start using JWT immediately
-* AWS wants to base all authen for their service catalog products on JWTs
-* Azure is asking for it without knowing we are looking at it
-* Cross team buy-in on longer term plan
-* Bring JIT access to the masses
-
-Acceptance Criteria:
-
-* JWT's are unique for each stage of a run including plan, apply and run tasks.
-* Generated during speculative plans and standard runs
-* Exposed as an environment variable in the terraform build environment.
-* Not stored to state unless practitioner specifically references it from Terraform.
-* Accessible on agent-based workloads including hooks
-* Given a TTL that corresponds to the system timeout on the current workload.
-* JWT metadata must include:
-  * id of the run
-  * workspace id of the run
-  * organization id of the run
-  * stage of the run. i.e. speculative plan, plan, apply, run.
-
-To think about:
-
-1. NTP syncronization to ensure time matches from client to server.
-1. X.509 certificate expiration management?
-1. Who is on the app-sec team? (Brian?)
-
 [1]: https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRoleWithWebIdentity.html
diff --git a/learn/vault/README.md b/learn/vault/README.md
new file mode 100644
index 0000000..d6253e1
--- /dev/null
+++ b/learn/vault/README.md
@@ -0,0 +1,37 @@
+# Vault
+
+Start the server:
+
+```bash
+$ vault server -dev
+```
+
+```bash
+モ vault export VAULT_ADDR=http://127.0.0.1:8200
+モ vault export VAULT_TOKEN=hvs.example
+モ vault kv put cubbyhole/rails session_secret=example
+Success! Data written to: cubbyhole/rails
+モ vault kv get cubbyhole/rails
+========= Data =========
+Key               Value
+---               -----
+session_secret    example
+モ vault kv get -field=session_secret cubbyhole/rails
+example
+```
+
+To create a new namespace for secrets you need to provide a path prefix.
+
+```bash
+モ vault secrets enable -path=rails kv
+Success! Enabled the kv secrets engine at: rails/
+モ vault secrets list
+Path          Type         Accessor              Description
+----          ----         --------              -----------
+cubbyhole/    cubbyhole    cubbyhole_75d064e5    per-token private secret storage
+identity/     identity     identity_d11fdd33     identity store
+rails/        kv           kv_6ca5f254           n/a
+secret/       kv           kv_c50fa680           key/value secret storage
+sys/          system       system_5e571326       system endpoints used for control, policy and debugging
+```
+