Infrastructure credentials on your desktop
KubeRocks keeps SSH credentials encrypted in local storage, using operating system secure storage through the Electron main process. The central service works with credential references rather than the SSH secrets stored in the vault.
Executions that require authentication files may materialize restricted temporary files locally. Local security also depends on protecting your session, operating system and device backups.
- A vault on your device. The desktop main process uses operating system secure storage to protect saved secrets.
- Explicit editing. The credential list keeps selection and search separate from the form; the secret stays locked until an edit action.
- References in the central service. Configurations use credential references, while authentication material is resolved in the authorized local workflow.
- Cluster controls. Security, Identity & Policy organizes tools such as Kyverno, Vault and Keycloak with requirements specific to each profile.
Your infrastructure stays under your control
You provide hosts and choose where the Kubernetes cluster runs. SSH access, permissions, networking, backups and cluster policies must reflect your environment requirements.
Shell, logs, editing and lifecycle operations use the operational paths in the product. Centralized inventory does not grant unrestricted execution permission.
What the central service receives
The product uses authentication and central services for configuration, references and sanitized operational data, including inventory and metrics when available. Operations combine local storage, connected infrastructure and central services; authentication and synchronization require connectivity.
Secret and ConfigMap use metadata in the supported inventory path. Secret values, private keys and kubeconfigs do not belong in inventory payloads.
Inventory with limited authority
The inventory agent architecture uses outbound HTTPS connections, a separate identity per cluster and read permissions. Inventory and operational actions follow separate paths, with permissions appropriate to each purpose.
Agent availability depends on configuration and rollout stage. The existing operational path remains separate.
AI assistance, when enabled
Optional AI features may send allowed evidence to the provider chosen by the user. The provider key is protected locally. Recommendations do not represent autonomous infrastructure repair.
Before enabling an integration, review the provider, allowed data and your organization policies.
Security also depends on operations
Access and configuration checks help identify failures before execution. Define appropriate permissions, keep components updated and monitor conditions in your environment.
Evaluate your scenario, protect your device and validate recovery before operating critical workloads.
References for planning your environment
Consult official documentation and confirm requirements for your chosen versions before operating in production.