@tangle-network/sandbox-cli 0.9.8 → 0.10.0
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/README.md +44 -0
- package/SKILL.md +18 -9
- package/dist/index.mjs +19 -19
- package/hub-reference.md +3 -2
- package/package.json +3 -3
package/README.md
CHANGED
|
@@ -77,6 +77,50 @@ tangle auth profiles
|
|
|
77
77
|
|
|
78
78
|
`tangle auth login` validates the supplied credential against `/v1/account/me`, which requires a valid token.
|
|
79
79
|
|
|
80
|
+
### The two surfaces
|
|
81
|
+
|
|
82
|
+
Commands address one of two services, and the two accept different credentials.
|
|
83
|
+
|
|
84
|
+
| Surface | Command families | Credential |
|
|
85
|
+
|---|---|---|
|
|
86
|
+
| Sandbox API | `sandbox`, `exec`, `ssh`, `fs`, `process`, `snapshot`, `secret`, `agent`, `fleet`, `batch`, `usage` | the session `tangle auth login` stores, or an `sk-tan-*` key |
|
|
87
|
+
| Platform control plane (`id.tangle.tools`) | `keys`, `workflows`, `hub` | an `sk-tan-*` key only |
|
|
88
|
+
|
|
89
|
+
The platform does not accept the sandbox session: it belongs to a different
|
|
90
|
+
audience. After a browser login the CLI therefore mints a short-lived platform
|
|
91
|
+
key from that session on the first platform command, caches it in the same
|
|
92
|
+
credential store, and replaces it before it expires. Nothing durable is written
|
|
93
|
+
for a surface you never use, and no long-lived key sits on disk.
|
|
94
|
+
|
|
95
|
+
An `sk-tan-*` key is used exactly as supplied on both surfaces, whether it
|
|
96
|
+
arrives through `--api-key`, `TANGLE_API_KEY`, or `tangle auth login --api-key`,
|
|
97
|
+
so a spawned sandbox and a CI job keep the credential they were given and no
|
|
98
|
+
mint replaces it. `TANGLE_HUB_CAPABILITY_TOKEN` serves the `hub` commands only.
|
|
99
|
+
|
|
100
|
+
### What the minted credential may do
|
|
101
|
+
|
|
102
|
+
The minted key lives for minutes, so the platform refuses key creation and
|
|
103
|
+
revocation through it: a credential that short must not add or destroy authority
|
|
104
|
+
that outlasts it.
|
|
105
|
+
|
|
106
|
+
- `tangle keys list` works after `tangle auth login`.
|
|
107
|
+
- `tangle keys create` and `tangle keys revoke` need a key you minted yourself:
|
|
108
|
+
set `TANGLE_API_KEY`, run `tangle auth login --api-key sk-tan-…`, or mint the
|
|
109
|
+
key in the web console.
|
|
110
|
+
|
|
111
|
+
Everything else on the control plane — `tangle workflows`, `tangle hub` — works
|
|
112
|
+
from the login alone.
|
|
113
|
+
|
|
114
|
+
`tangle auth status` reports both surfaces. It exits non-zero when either one
|
|
115
|
+
REFUSES the stored credential — a behaviour change for a script that gated on
|
|
116
|
+
the old sandbox-only check, and the point of it: the platform rejecting the
|
|
117
|
+
credential used to be reported as success. An unreachable platform is a
|
|
118
|
+
different answer and exits zero, because an outage says nothing about the
|
|
119
|
+
credential; read `platform.reachable` in `--json` to gate platform work.
|
|
120
|
+
`--base-url` names the sandbox host for BOTH halves: the session is checked
|
|
121
|
+
there, and the platform credential is minted there, so the two lines of the
|
|
122
|
+
answer always describe one deployment.
|
|
123
|
+
|
|
80
124
|
## Command Surface
|
|
81
125
|
|
|
82
126
|
Top-level command groups:
|
package/SKILL.md
CHANGED
|
@@ -12,7 +12,12 @@ All commands support `--help` for inline reference.
|
|
|
12
12
|
|
|
13
13
|
## Auth
|
|
14
14
|
|
|
15
|
-
|
|
15
|
+
Commands address one of two services. Sandbox commands (`sandbox`, `exec`,
|
|
16
|
+
`ssh`, `fs`, `snapshot`, `secret`, `agent`, …) address the sandbox API. Platform
|
|
17
|
+
commands (`keys`, `workflows`, `hub`) address the control plane at
|
|
18
|
+
`id.tangle.tools`, which accepts only an `sk-tan-*` key.
|
|
19
|
+
|
|
20
|
+
Sandbox command auth modes, resolved in order:
|
|
16
21
|
|
|
17
22
|
| Priority | Source | Set via |
|
|
18
23
|
|----------|--------|--------|
|
|
@@ -20,14 +25,18 @@ Generic command auth modes, resolved in order:
|
|
|
20
25
|
| 2 | Env var | `TANGLE_API_KEY` |
|
|
21
26
|
| 3 | Profile store | `tangle auth login` (keychain or file) |
|
|
22
27
|
|
|
23
|
-
|
|
24
|
-
|
|
25
|
-
|
|
26
|
-
|
|
27
|
-
|
|
28
|
-
|
|
29
|
-
|
|
30
|
-
|
|
28
|
+
Platform commands resolve auth in the same order, with one step added: the
|
|
29
|
+
session that `tangle auth login` stores is not a platform credential, so the CLI
|
|
30
|
+
mints a short-lived platform key from it on first use and refreshes it as
|
|
31
|
+
needed. Hub commands also accept `TANGLE_HUB_CAPABILITY_TOKEN`, ranked directly
|
|
32
|
+
below `--api-key`; other platform commands do not, because that token
|
|
33
|
+
authenticates `/v1/hub/exec` alone.
|
|
34
|
+
|
|
35
|
+
The minted key lives for minutes, so the platform refuses key creation and
|
|
36
|
+
revocation through it. `tangle keys list` works from a browser login; `tangle
|
|
37
|
+
keys create` and `tangle keys revoke` need a key you minted yourself
|
|
38
|
+
(`TANGLE_API_KEY`, `tangle auth login --api-key`, or the web console). A stored
|
|
39
|
+
`sk-tan-*` is presented as-is and never minted over.
|
|
31
40
|
|
|
32
41
|
**Inside a sandbox:** `tangle` is automatically authenticated.
|
|
33
42
|
No extra authentication is needed.
|