@@ -40,6 +40,17 @@ unseal_namespace: "imperative"
40
40
41
41
This relies on [kubernetes.core](https://docs.ansible.com/ansible/latest/collections/kubernetes/core/k8s_module.html)
42
42
43
+ ## Vault out of the box configuration
44
+
45
+ This role configures four secret paths in vault:
46
+
47
+ 1. ` secret/global` - Any secret under this path is accessible in read-only only to all clusters known to ACM (hub and spokes)
48
+ 2. `secret/hub` - Any secret under this path is accessible in read-only only to the ACM hub cluster
49
+ 3. `secret/<fqdn.of.spoke.cluster>` - Any secret under this path is accessible in read-only only to the spoke cluster
50
+ 4. `secret/pushsecrets` - Any secret here can be accessed in read and write mode to all clusters known to ACM. This area can
51
+ be used with ESO's `PushSecrets` so you can push an existing secret from one namespace, to the vault under this path and
52
+ then it can be retrieved by an `ExternalSecret` either in a different namespace *or* from an entirely different cluster.
53
+
43
54
# # Values secret file format
44
55
45
56
Currently this role supports two formats : version 1.0 (which is the assumed
@@ -55,49 +66,9 @@ By default, the first file that will looked up is
55
66
The paths can be overridden by setting the environment variable `VALUES_SECRET` to the path of the
56
67
secret file.
57
68
58
- The values secret yaml files can be encrypted with `ansible-vault`. If the role detects they are encrypted, the password to
69
+ The values secret YAML files can be encrypted with `ansible-vault`. If the role detects they are encrypted, the password to
59
70
decrypt them will be prompted when needed.
60
71
61
- # ## Version 1.0
62
-
63
- Here is a well-commented example of a version 1.0 file :
64
-
65
- ` ` ` yaml
66
- ---
67
- # By default when a top-level 'version: 1.0' is missing it is assumed to be '1.0'
68
- # NEVER COMMIT THESE VALUES TO GIT
69
-
70
- secrets:
71
- # These secrets will be pushed in the vault at secret/hub/test The vault will
72
- # have secret/hub/test with secret1 and secret2 as keys with their associated
73
- # values (secrets)
74
- test:
75
- secret1: foo
76
- secret2: bar
77
-
78
- # This ends up as the s3Secret attribute to the path secret/hub/aws
79
- aws:
80
- s3Secret: test-secret
81
-
82
- # This will create the vault key secret/hub/testfoo which will have two
83
- # properties 'b64content' and 'content' which will be the base64-encoded
84
- # content and the normal content respectively
85
- files:
86
- testfoo: ~/ca.crt
87
- # These secrets will be pushed in the vault at secret/region1/test The vault will
88
- # have secret/region1/test with secret1 and secret2 as keys with their associated
89
- # values (secrets)
90
- secrets.region1:
91
- test:
92
- secret1: foo1
93
- secret2: bar1
94
- # This will create the vault key secret/region2/testbar which will have two
95
- # properties 'b64content' and 'content' which will be the base64-encoded
96
- # content and the normal content respectively
97
- files.region2:
98
- testbar: ~/ca.crt
99
- ` ` `
100
-
101
72
# ## Version 2.0
102
73
103
74
Here is a version 2.0 example file (specifying `version : 2.0` is mandatory in this case):
@@ -210,6 +181,46 @@ secrets:
210
181
ini_key: aws_secret_access_key
211
182
` ` `
212
183
184
+ # ## Version 1.0
185
+
186
+ Here is a well-commented example of a version 1.0 file :
187
+
188
+ ` ` ` yaml
189
+ ---
190
+ # By default when a top-level 'version: 1.0' is missing it is assumed to be '1.0'
191
+ # NEVER COMMIT THESE VALUES TO GIT
192
+
193
+ secrets:
194
+ # These secrets will be pushed in the vault at secret/hub/test The vault will
195
+ # have secret/hub/test with secret1 and secret2 as keys with their associated
196
+ # values (secrets)
197
+ test:
198
+ secret1: foo
199
+ secret2: bar
200
+
201
+ # This ends up as the s3Secret attribute to the path secret/hub/aws
202
+ aws:
203
+ s3Secret: test-secret
204
+
205
+ # This will create the vault key secret/hub/testfoo which will have two
206
+ # properties 'b64content' and 'content' which will be the base64-encoded
207
+ # content and the normal content respectively
208
+ files:
209
+ testfoo: ~/ca.crt
210
+ # These secrets will be pushed in the vault at secret/region1/test The vault will
211
+ # have secret/region1/test with secret1 and secret2 as keys with their associated
212
+ # values (secrets)
213
+ secrets.region1:
214
+ test:
215
+ secret1: foo1
216
+ secret2: bar1
217
+ # This will create the vault key secret/region2/testbar which will have two
218
+ # properties 'b64content' and 'content' which will be the base64-encoded
219
+ # content and the normal content respectively
220
+ files.region2:
221
+ testbar: ~/ca.crt
222
+ ` ` `
223
+
213
224
Internals
214
225
---------
215
226
0 commit comments