@kitsy/cnos-docs 1.9.1 → 1.9.2
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
package/docs/cli/secret.mdx
CHANGED
|
@@ -7,8 +7,12 @@ description: Set, get, list, and delete secrets through configured vaults.
|
|
|
7
7
|
|
|
8
8
|
```bash
|
|
9
9
|
cnos secret set app.token super-secret --vault default
|
|
10
|
+
cnos secret set app.token --vault default
|
|
11
|
+
printf "super-secret" | cnos secret set app.token --vault default --stdin
|
|
10
12
|
cnos secret get app.token --vault default --reveal
|
|
11
13
|
cnos secret list
|
|
12
14
|
cnos secret list --reveal
|
|
13
15
|
cnos secret delete app.token
|
|
14
16
|
```
|
|
17
|
+
|
|
18
|
+
If you omit `[value]`, CNOS prompts for a masked value interactively so the secret does not have to appear in shell history. In non-interactive environments, pass the value explicitly or use `--stdin`.
|
package/docs/cli/vault.mdx
CHANGED
|
@@ -16,3 +16,5 @@ cnos vault remove default
|
|
|
16
16
|
For local vaults, `cnos vault create <name>` initializes the encrypted keystore immediately. CNOS prompts for a passphrase if one is not already available through `CNOS_SECRET_PASSPHRASE_<VAULT>`, `CNOS_SECRET_PASSPHRASE`, or the OS keychain.
|
|
17
17
|
|
|
18
18
|
`cnos vault auth <name>` re-authenticates an existing vault and fails on wrong credentials. Successful auth writes a derived session key under `~/.cnos/secrets/sessions`, so later CNOS commands can reuse it across shells until you run `cnos vault logout <name>` or `cnos vault logout --all`. With `--store-keychain`, CNOS also stores the derived key in the OS keychain.
|
|
19
|
+
|
|
20
|
+
After local vault auth, `cnos secret set <path> --vault <name>` can prompt for a masked secret value interactively when you omit `[value]`.
|
|
@@ -31,9 +31,11 @@ Create a local vault and authenticate it:
|
|
|
31
31
|
```bash
|
|
32
32
|
cnos vault create default
|
|
33
33
|
cnos vault auth default
|
|
34
|
-
cnos secret set app.token
|
|
34
|
+
cnos secret set app.token --vault default
|
|
35
35
|
```
|
|
36
36
|
|
|
37
|
+
CNOS prompts for the secret with masked input when you omit the value, which keeps it out of shell history. For non-interactive scripts, pass the secret over `--stdin`.
|
|
38
|
+
|
|
37
39
|
If the project later becomes a monorepo, do not create a second `.cnos`. Convert the existing repo and add children:
|
|
38
40
|
|
|
39
41
|
```bash
|
package/docs/guides/secrets.mdx
CHANGED
|
@@ -10,11 +10,17 @@ Local vault:
|
|
|
10
10
|
```bash
|
|
11
11
|
cnos vault create default
|
|
12
12
|
cnos vault auth default
|
|
13
|
-
cnos secret set app.token
|
|
13
|
+
cnos secret set app.token --vault default
|
|
14
14
|
```
|
|
15
15
|
|
|
16
16
|
`cnos vault create default` initializes the local encrypted vault immediately. If CNOS cannot resolve a passphrase from env or keychain, it prompts interactively. `cnos vault auth default` is only for re-authenticating an existing vault and rejects wrong passphrases.
|
|
17
17
|
|
|
18
|
+
When `[value]` is omitted, `cnos secret set` prompts for a masked secret value so it does not have to appear in shell history. For non-interactive pipelines, use `--stdin` instead:
|
|
19
|
+
|
|
20
|
+
```bash
|
|
21
|
+
printf "super-secret" | cnos secret set app.token --vault default --stdin
|
|
22
|
+
```
|
|
23
|
+
|
|
18
24
|
Environment-backed vault:
|
|
19
25
|
|
|
20
26
|
```bash
|
package/manifest.yml
CHANGED