You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
* fix: add helper for AWS
* fix: pr ci
* feat: add hashivault AWS IAM Auth
minor CI tweak
* fix: hashivault tests and implementation
* fix: add more tests to hashivault
* fix: add docs to document additional hashicorp features
+semver: feat
SONAR_TOKEN: ${{ secrets.SONAR_TOKEN }} # Generate a token on Sonarcloud.io, add it to the secrets of this repo with the name SONAR_TOKEN (Settings > Secrets > Actions > add new repository secret)
- see [special consideration hashivault](#special-consideration-for-hashicorpvault)
22
37
23
-
The main driver is to use component level configuration objects, if stored in a `"namespaced"` manner e.g. in AWS ParamStore as `/nonprod/component-service-a/configVar`, however this is not a requirement and the param name can be whatever. Though whilst using some sort of a organised manner it will be more straight forward to allow other services to consume certain secrets/params based on resource/access policies.
38
+
The main driver is to use component level configuration objects, if stored in a `"namespaced"` manner e.g. in AWS ParamStore as `/nonprod/component-service-a/configVar`, however this is not a requirement and the param name can be whatever. Though whilst using some sort of a organised manner it will be more straight forward to allow other services to consume certain secrets/params based on resource/access policies.
24
39
25
40
> Beware size limitation with certain config/vault implementations. In which case it's best to split certain items up e.g. TLS certs `/nonprod/component-service-a/pub-cert`, `/nonprod/component-service-a/private-cert`, `/nonprod/component-service-a/chain1-cert`, etc...
26
41
@@ -46,13 +61,17 @@ ConfigManager comes packaged as a CLI for all major platforms, to see [download/
46
61
47
62
For more detailed usage you can run -h with each subcommand and additional info can be found [here](./docs/commands.md)
48
63
49
-
## Config Tokens
64
+
## __Config Tokens__
50
65
51
66
The token is made up of 3 parts:
52
67
53
-
-`AWSSECRETS` the strategy identifier to choose at runtime
68
+
### Implementation indicator
54
69
55
-
-`#` separator - used for separating the implementation indicator and the look up value.
70
+
e.g. `AWSSECRETS` the strategy identifier to choose at runtime
71
+
72
+
### __Token Separator__
73
+
74
+
e.g. `#` - used for separating the implementation indicator and the look up value.
56
75
57
76
> The default is currently `#` - it will change to `://` to allow for a more natural reading of the "token". you can achieve this behaviour now by either specifying the `-s` to the CLI or ConfigManager public methods, like below.
58
77
@@ -72,11 +91,12 @@ Alternatively you can use the helper methods for Yaml or Json tagged structs - s
72
91
73
92
If contents of the `AWSSECRETS#/appxyz/service1-password` are a string then `service1-password` will be the key and converted to UPPERCASE e.g. `SERVICE1_PASSWORD=som3V4lue`
74
93
75
-
### KeySeparator
94
+
### __Key Separator__
76
95
77
96
Specifying a key seperator on token items that can be parsed as a K/V map will result in only retrieving the specific key from the map.
78
97
79
98
e.g. if contents of the `AWSSECRETS#/appxyz/service1-db-config` are parseable into the below object
99
+
80
100
```json
81
101
{
82
102
"host": "db.internal",
@@ -113,7 +133,6 @@ db:
113
133
114
134
If your config parameter matches the config interface, you can also leave the entire token to point to the `db` key
115
135
116
-
117
136
```yaml
118
137
app:
119
138
name: xyz
@@ -132,6 +151,20 @@ db: {
132
151
}
133
152
```
134
153
154
+
### Additional Token Config
155
+
156
+
Suffixed `[]` with `role:` or `version:` specified inside the brackets and comma separated
157
+
158
+
order is not important, but the `role:` keyword must be followed by the role string
159
+
160
+
e.g. `VAULT://baz/bar/123|d88[role:arn:aws:iam::1111111:role/i-orchestration,version:1082313]`
161
+
162
+
Currently only supporting version and role but may be extended in the future.
163
+
164
+
- role is used with `VAULT` `aws_iam` auth type. Specifying it on a token level as opposed to globally will ensure that multiple roles can be used provided that the caller has the ability to assume them.
165
+
166
+
- version can be used within all implementations that support versioned config items e.g. `VAULT`, `GCPSECRETS` , `AWSSECRETS`, `AZKVSECRET`. If omitted it will default to the `LATEST`.
167
+
135
168
### Special consideration for AZKVSECRET
136
169
137
170
For Azure KeyVault the first part of the token needs to be the name of the vault.
@@ -147,12 +180,15 @@ For Azure KeyVault the first part of the token needs to be the name of the vault
147
180
### Special consideration for HashicorpVault
148
181
149
182
For HashicorpVault the first part of the token needs to be the name of the mountpath. In Dev Vaults this is `"secret"`,
150
-
e.g.:
183
+
e.g.:`VAULT://secret___demo/configmanager|test`
151
184
152
-
`VAULT://secret___demo/configmanager|test`
185
+
or if the secrets are at another location: `VAULT://another/mount/path__config/app1/db`
153
186
154
187
The hardcoded separator cannot be modified and you must separate your `mountPath` with `___` (3x `_`) followed by the key to the secret.
155
188
189
+
#### AWS IAM auth to vault
190
+
191
+
when using Vault in AWS - you can set the value of the `VAULT_TOKEN=aws_iam` this will trigger the AWS Auth login as opposed to using the local token.
156
192
157
193
The Hashicorp Vault functions in the same exact way as the other implementations. It will retrieve the JSON object and can be looked up within it by using a key separator.
0 commit comments