Accounts, credentials, and permissions
Accounts, credentials, and grants determine whose identity a request uses, when access expires, and which operations are allowed.
Identity model
| Concept | Purpose | When it ends |
|---|---|---|
| Account | A Kubernetes ServiceAccount representing an access identity | Deleted when the account is revoked |
| Credential | A token inside a kubeconfig that authenticates requests | Expires, or its account is revoked |
| Grant | Permissions assigned through an existing Role or ClusterRole | Ends when the corresponding binding is removed |
An account can have several credentials. All valid credentials share its permissions. Issuing another credential does not replace earlier ones, and changing permissions does not extend credential expiry. The account and its grants remain after a token expires.
The account namespace holds the ServiceAccount and defaults to kticket-users. The target namespace limits a grant’s scope; it can be different from the account namespace. Use a dedicated account namespace. An existing ServiceAccount with the same name is reused and brought under kticket management, making it eligible for account revocation.
For example, alice in kticket-users authenticates as system:serviceaccount:kticket-users:alice. A local user alias in the kubeconfig does not change this identity.
Permission changes
- Issuance adds the selected grants to existing permissions.
--access noneadds no grants and does not clear existing access. - A RoleBinding limits permissions to its target namespace; a ClusterRoleBinding grants access cluster-wide. kticket uses existing roles and does not create custom role rules.
- Access editing adds, replaces, or removes managed grants. A YAML configuration describes the complete desired set of managed grants.
- Kubernetes RBAC permissions are additive. External bindings and group assignments can still provide access; kticket displays these grants as read-only.
The grant list is not a complete inventory of effective permissions. To check a specific operation, use the TUI’s authorization check or kticket access check. See the CLI reference for examples.
Replacing a grant can briefly interrupt access. If a change fails partway through, completed operations are not rolled back. Reload the account and review a new plan before applying it; see troubleshooting.
kticket does not expire grants automatically, assign separate permissions to tokens belonging to one account, or revoke a single token independently. Use separate accounts when you need independent permissions or revocation.
Token lifetime
The requested duration defaults to 24h, with a minimum of 10m. The API server may adjust the actual lifetime. Use the expiry shown in the issuance result.
Recipients can load the generated kubeconfig directly with kubectl without installing kticket. The file contains a bearer token: protect it as a credential and share it through a trusted channel.
Revocation
kticket revoke and the TUI’s revoke action delete the ServiceAccount and clean up its managed bindings. This affects every credential for that account. Kubernetes rejects the tokens when it validates them again. Recreating an account with the same name does not make old tokens valid.
Revocation does not terminate established connections or remove namespaces, shared roles, external bindings, or local kubeconfig files.
If account deletion succeeds but binding cleanup fails, inspect and remove the remaining bindings with administrator credentials before recreating the account. This prevents the new account from inheriting leftover permissions.
Credential records
Run kticket list --credentials, or press v in the TUI account list or access editor, to see credential IDs, issuance and expiry times, and available audit IDs.
History covers recorded credentials only. Missing history does not establish that an account has no valid tokens. An “unexpired” record describes its timestamp, not a guarantee that authentication or authorization will succeed. Deleting a record does not revoke its token.
When the cluster records the relevant Kubernetes audit events, audit IDs can connect issuance with later requests. Correlation depends on the audit information the cluster provides. Locally generated credential IDs cannot provide native audit correlation, and copies of the same kubeconfig cannot be distinguished.
Administrator permissions
The required permissions depend on the operation:
| Operation | Required access |
|---|---|
| Issue | Read namespaces, roles, accounts, and bindings; create the account namespace and ServiceAccount when missing; update account labels and annotations; create bindings; create serviceaccounts/token |
| List | List managed ServiceAccounts, RoleBindings across namespaces, and ClusterRoleBindings; read a specified account namespace |
| Revoke | Read and delete the managed ServiceAccount; list and delete matching managed bindings |
| Manage grants | Read accounts, target namespaces, roles, and bindings; create/delete bindings and update their management labels |
| Check authorization | Read the account and any target namespace; create subjectaccessreviews.authorization.k8s.io |
| TUI suggestions | API discovery and read/list access to the relevant objects |
Kubernetes RBAC binding restrictions still apply. Server-side dry runs also require write permissions. A restricted administrator role must cover the operations and resource scopes used by the workflow. Activating a license does not grant Kubernetes administrator permissions.