How do I change my service account password?
The Shturval platform connects to the infrastructure (vCenter, oVirt, OpenStack, etc.) and to the storage (when using CSI) using service accounts. If the password or login of the service management system has changed in the system itself (vCenter, Engine, cloud), they need to be updated in the platform. Credentials can be set in two places: in the Provider Instance (infrastructure and often CSI) and separately for the CSI Provisioner if it uses its own secrets.
Where credentials are stored
| What uses credentials | Where are they asked | Where to change password/login |
|---|---|---|
| Infrastructure Provider (Cluster API: create VMs, nodes) | Provider instance in the platform | Editing a Provider Instance (see below) |
| CSI Provisioner if using the same credentials as the provider | The same as those from the provider (the platform substitutes them in CSI) | It is enough to change the provider in the instance |
| CSI Provisioner if using separate credentials | Secret or parameters in the cluster (for example, Ceph, NFS) | Editing Secret/parameters in the cluster where CSI is running |
Below is how to change the password in each case.
Changing the password in the provider instance
Provider credentials (login, password, token or key if necessary) are specified when creating and editing a provider instance. Changing the password is performed through the platform GUI.
Steps
- Go to Providers → Provider Configuration.
- Find the desired provider instance (vCenter, oVirt, OpenStack, etc.) and open it for editing (edit button or “Configuration”).
- In the form, change the Password field (and, if necessary, Username or other account fields - depending on the type of provider).
- Click Test connection to ensure that the new credentials are accepted by the provider API.
- Click Save.
After saving, the platform will update the stored credentials. Controllers (including Cluster API and, when CSI is enabled, components that use the same data from the provider instance) will use the new password during subsequent operations. No further action is required.
By type of provider
- VMware vSphere: Username and Password fields in the instance form. Login format:
username@domain. See VMware vSphere. - oVirt and similars: “URL Engine”, “Username”, “Password”. See oVirt and similar providers.
- OpenStack: for the “Service User” type - “Name (username)” and “Password”; when “Token” - the token is updated. See OpenStack.
- Yandex Cloud: when using a service account, the JSON key (Service Account key) is updated. See Yandex Cloud.
- vCloud Director, Basis Dynamix, Shturval v2: credentials are specified in the form of an instance; the password (or key for Shturval v2) is changed there.
CSI Provisioner: when credentials are shared with the provider
If your cluster platform uses CSI based on the same provider (for example, VMware vSphere CSI or oVirt CSI) and the CSI integration option was enabled when you created the cluster, the credentials for CSI are typically taken from the same provider instance. In this case, it is enough to change the password (and, if necessary, login) in the provider instance - as described above. There is no need to configure CSI separately after changing the password.
After changing the password, make sure that in vCenter/oVirt the service UZ is still assigned the rights required for CSI (for example, for vSphere - service role No. 2). See VMware vSphere, oVirt and similar providers.
CSI Provisioner: when credentials are separate
Some CSI drivers use not infrastructure provider credentials, but individual secrets in the cluster (login/password or storage access keys). For example:
- Ceph RBD / CephFS - Secret names with Ceph keys (admin, user) are specified in the StorageClass or in the CSI parameters. These secrets are created in the cluster namespace and filled with keys from
ceph auth get, etc. - NFS - depending on the implementation, your own connection parameters and, if necessary, secrets can be used.
In such cases, the password or key must be changed where they are stored - in the cluster in which the corresponding CSI is deployed:
- Determine which Secret (or which configuration parameter) the CSI module uses to access the store. This may be specified in the StorageClass (e.g.
provisionerSecret,nodeStageSecret) or in the CSI system service description. - Open cluster → Storage (or Administration → Storage) → Secrets (or the corresponding namespace where the secret was created).
- Edit the desired Secret: update the password or key field (the values in the Secret are usually stored in base64; when editing through the GUI can take a ready-made value or encode it itself).
- After saving the Secret, the CSI pods (node plugin, controller) will start using the new data the next time they access the storage. If necessary, restart the CSI pods according to the module documentation.
For more information about StorageClass parameters and secrets for Ceph, see StorageClasses - sections on Ceph RBD / CephFS type.