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
Create a file in `~/.skms/credentials.yaml` which looks like the following:
143
-
```yaml
144
-
endpoint: "api.skms.mycompany.com"
145
-
username: <username>
146
-
password: <password>
147
-
```
141
+
## Examples
148
142
149
-
## Example
150
-
151
-
See `examples/` folder:
143
+
See [examples/](https://github.com/adobe/ops-cli/tree/master/examples) folder:
152
144
- cassandra-stress - n-node cassandra cluster used for stress-testing; a basic stress profile is included
145
+
- spin up a Kubernetes clsuter
153
146
- distinct `ops` features
154
147
155
148
## Usage help
@@ -526,14 +519,11 @@ optional arguments:
526
519
ops clusters/centos7.yaml packer build
527
520
```
528
521
529
-
## Development
530
-
531
-
### Running tests
522
+
## Secrets Management
532
523
533
-
- docker: `buildrunner -f buildrunner.yaml`
534
-
- on your machine: `py.test tests`
524
+
There are cases where you need to reference sensitive data in your `cluster.yaml` file (credentials, passwords, tokens etc). Given that the cluster configuration file can be stored in a version control system (such as Git), the best practice is to not put sensitive data in the file itself. Instead, we can use `ops-cli` to fetch the desired credentials from a secrets manager such as Vault or Amazon SSM, at runtime.
535
525
536
-
## Secrets Management
526
+
### Vault
537
527
538
528
Ops can manage the automatic generation of secrets and their push in Vault, without actually persisting the secrets in the cluster file.
539
529
A cluster file will only need to use a construct like the following:
@@ -548,6 +538,20 @@ Which will translate behind the scenes in :
548
538
This allows us to just refer in cluster files a secret that actually exists in vault and make sure we only generate it once - if it was already created by os or any other system, we will just use what is already there.
549
539
The reference is by means of fixed form jinja call added to the cluster file, which ends up interpretted later during the templating phase.
550
540
541
+
### Amazon Secrets Manager (SSM)
542
+
543
+
Amazon offers the possibility to use their [Secrets Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/what-is-systems-manager.html) in order to manage configuration data such as credentials, passwords and license keys.
544
+
545
+
We can use `ops-cli` to fetch the sensitive data from SSM, at runtime. Just define this in your cluster configuration file (eg. `mycluster.yaml`).
`ops-cli` will read the SSM value by running a command similar to: `AWS_PROFILE=aam-npe aws ssm get-parameter --name "/my/ssm/path" --region us-east-1 --with-decryption`.
552
+
Note that you can specify the AWS region via `read_ssm(aws_profile='myprofile', region_name='us-west-2')`.
553
+
554
+
551
555
## Using jinja2 filters in playbooks and terraform templates
552
556
553
557
You can register your own jinja2 filters that you can use in the cluster config file, terraform templates and ansible playbooks
0 commit comments