Creating an initial user

Create VSP One SDS Block initial users to run a REST API or CLI for verifying the storage cluster configuration from the controller node. When using session authentication, see the VSP One SDS Block System Administrator Operation Guide.

Note:

VSP One SDS Block has a self-signed certificate imported immediately after installation. If you continue to use the REST API or CLI, you may receive a warning message about the server certificate.

If you see a warning message, check the IP address or host name of the request destination, then refer to Action to be taken when a warning message about a server certificate appears in the VSP One SDS Block System Administrator Operation Guide and follow the warning ignore method for each execution environment listed in the bulleted list.

By importing the server certificate in step 3, the warning message disappears.

Log in to the EC2 instance for a controller node.
Change the password of the built-in user. The parameters and values required to change the password are as follows:
- userId: "admin"
- currentPassword: "hsds-admin"
- newPassword: New password
REST API: PATCH /v1/objects/users/<userId>/password

CLI: user_password_set

The changed password has an expiration time. You can confirm the expiration time from the execution result of the command. Note that the default expiration time is 42 days.

Note:
For details about a password policy, see the system default values indicated in Editing user authentication settings in the VSP One SDS Block System Administrator Operation Guide.
When you are importing server certificates into VSP One SDS Block, see Importing signed certificates for an SSL/TLS connection in the VSP One SDS Block System Administrator Operation Guide, and import a trusted certificate signed by a built-in user in step 2 into VSP One SDS Block.

To communicate securely with VSP One SDS Block, we strongly recommend that you configure SSL/TLS communication and import server certificates.
Create two users who belong to the "SecurityAdministrators" and "ServiceAdministrators" built-in user groups.

You can let one user belong to both "SecurityAdministrators" and "ServiceAdministrators".

Because a user in the system must be permitted to use the console interface, permit the use of the console interface.
For the REST API:
- userId: User ID
- Password: Password
- userGroupIds: "SecurityAdministrators" and "ServiceAdministrators"
- authentication: local
- isEnabledConsoleLogin: true
REST API: POST /v1/objects/users

CLI: user_create
CAUTION:

Grant the console login permission to one or both of the users to be added.
For security, each user must change the initial password before the initial use after the administrator creates users.
Note:
The user can operate the console interface only after the password is changed by that user.

Change the password of the user created in the "SecurityAdministrators" user group. The parameters and values required to change the password are as follows.

For the REST API:
- userId: ID of the user created in the "SecurityAdministrators" user group
- currentPassword: Password used when the user was created
- newPassword: New password
REST API: PATCH /v1/objects/users/<userId>/password

CLI: user_password_set
For security, invalidate the built-in user. Use the credentials changed in step 5.
If the initial user created in step 4 is not permitted to use the console interface, the built-in user cannot be invalidated. Permit a user other than the built-in user to use the console interface.

The parameters and values required to invalidate the built-in user are as follows.

For the REST API:
- userId: "admin"
- isEnabled: "false"
REST API: PATCH /v1/objects/users/<userId>

CLI: user_set