@dmgnr/kuber 2.5.2 → 2.6.1-rc1
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 +59 -0
- package/dist/index.js +96 -95
- package/package.json +1 -1
package/README.md
CHANGED
|
@@ -86,6 +86,65 @@ The default login is scoped to the current user and the authenticated identity
|
|
|
86
86
|
is available to every v2 command. `login`, `logout`, `whoami`, and global
|
|
87
87
|
`maintenance` are the only commands that run without a loaded project configuration.
|
|
88
88
|
|
|
89
|
+
### API Keys
|
|
90
|
+
|
|
91
|
+
Create API keys for automation or other non-interactive clients. Keys belong to a
|
|
92
|
+
user and carry explicit capabilities; use the smallest capability set the task
|
|
93
|
+
needs. The `--workspace` option further restricts Kubernetes access to one
|
|
94
|
+
workspace. Capabilities describe *what* the key may do, while workspace scope
|
|
95
|
+
describes *where* its Kubernetes access applies; neither replaces the other.
|
|
96
|
+
|
|
97
|
+
Valid capabilities are `kubernetes:read`, `kubernetes:write`,
|
|
98
|
+
`kubernetes:exec`, `users:read`, `users:write`, `sessions:revoke`, and
|
|
99
|
+
`platform:adopt`. For example, a deployment key that only reads and updates
|
|
100
|
+
resources in the `website` workspace can be created with:
|
|
101
|
+
|
|
102
|
+
```bash
|
|
103
|
+
kuber users keys create deployer --capabilities kubernetes:read,kubernetes:write --workspace website
|
|
104
|
+
```
|
|
105
|
+
|
|
106
|
+
The default expiry is 90 days. Set `--expires-days` to an integer from 1 to 365,
|
|
107
|
+
or explicitly use `none` for a key that does not expire:
|
|
108
|
+
|
|
109
|
+
```bash
|
|
110
|
+
kuber users keys create deployer --capabilities kubernetes:read --expires-days 30
|
|
111
|
+
kuber users keys create deployer --capabilities kubernetes:read --expires-days none
|
|
112
|
+
```
|
|
113
|
+
|
|
114
|
+
The raw token is printed once at creation. Copy it directly into a secret
|
|
115
|
+
manager; it cannot be retrieved later. List keys (optionally filtered by owner)
|
|
116
|
+
to find the key ID, then revoke a compromised or retired key:
|
|
117
|
+
|
|
118
|
+
```bash
|
|
119
|
+
kuber users keys ls
|
|
120
|
+
kuber users keys ls deployer
|
|
121
|
+
kuber users keys revoke deployer <key-id>
|
|
122
|
+
```
|
|
123
|
+
|
|
124
|
+
Revoking a key immediately prevents it from authenticating. Do not place API
|
|
125
|
+
tokens in source control, command-line arguments, or committed configuration.
|
|
126
|
+
|
|
127
|
+
### CI Integration
|
|
128
|
+
|
|
129
|
+
Create a dedicated automation user/key with only the capabilities required by
|
|
130
|
+
the CI job, and set the token as a masked repository or organization secret
|
|
131
|
+
(for example, `KUBER_API_TOKEN`). Expose the secret as an environment variable
|
|
132
|
+
for the job step. Commands that use the v2 API can then authenticate with that
|
|
133
|
+
token without an interactive `kuber login`:
|
|
134
|
+
|
|
135
|
+
```yaml
|
|
136
|
+
- name: Deploy with kuber
|
|
137
|
+
env:
|
|
138
|
+
KUBER_API_TOKEN: ${{ secrets.KUBER_API_TOKEN }}
|
|
139
|
+
run: kuber up
|
|
140
|
+
```
|
|
141
|
+
|
|
142
|
+
Use the CI provider's secret store, never commit the token or print it in logs.
|
|
143
|
+
For example, a workspace-scoped key with `kubernetes:read,kubernetes:write`
|
|
144
|
+
allows deployment operations in that workspace, but does not grant user
|
|
145
|
+
administration, exec, or platform adoption. Add a capability only when the job
|
|
146
|
+
needs that operation, and choose `--workspace` to limit its Kubernetes scope.
|
|
147
|
+
|
|
89
148
|
### Roles and Authorization
|
|
90
149
|
|
|
91
150
|
The server grants capabilities through three roles:
|