1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
|
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.
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.
Reference Links:
* [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/)
Related Field Requests:
* [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)
To Learn:
* [ ] the OIDC flows.
* [ ] the Vault API.
* [ ] the key material available to a Terraform run context.
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.
1. Inject secrets into run.
```plaintext
Is it like this?
------- ---------------- ----------
| TFC | | OIDC Provider| | runner |
------- ---------------- ----------
| | |
|--- request token ----->| |
| | |
|<----- return token ----| |
| |
| |
| |
|---- inject secrets ---------------------->|
or like this ...
------- ---------- ---------
| TFC | | Runner | | Vault |
------- ---------- ---------
* aws access/secret
-------->
* job description
* a way to get key material from Vault. (token)
* config version data.
--------> give me the secrets
* do the thing
<------- return the job status
1. schedule run of apply.
2. key material to do the apply.
* aws access/secret key
* environment vars
3. low ttl key material to do the things.
```
# 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. Who is on the app-sec team? (Brian?)
1. x.509 certificate expiration.
|
