Managing Users and Roles

Managing Users and Roles through the UI

1. Go to the service dashboard for your service.
2. Click Service Credentials to open the Service Credentials section.
3. Click __New Credential**.
4. Choose a descriptive name for your new credential.
5. (Optional) Specify whether the new credentials use a public or private endpoint. Use either { "service-endpoints": "public" } / { "service-endpoints": "private" } in the Add Inline Configuration Parameters field to generate connection strings that use the specified endpoint. Use of the endpoint is not enforced. It just controls which hostnames are in the connection strings. Public endpoints are generated by default.
6. Click Add to provision the new credentials. A username and password, and an associated etcd user is auto-generated.

The new credentials appear in the table, and the connection strings are available as JSON in a click-to-copy field under View Credentials.

Creating a user from the CLI or API doesn't automatically populate that user's connection strings into Service Credentials. If you want to add them there, you can create a new credential with the existing user information. Enter the username and password in the JSON field under Add Inline Configuration Parameters. For example, {"existing_credentials":{"username":"Robert","password":"supersecure"}}. Basically, you send in the username and password, and Service Credentials generates the connection strings with the credentials filled in.

Generating credentials from an existing user does not check for or create that user.

Users that you create through Service Credentials are given the roles readWriteAnyDatabase and dbAdminAnyDatabase.

If you need users that are created from Service Credentials to have a different role, you can use the admin user to change their role.

Managing Users and Roles through the CLI

If you need users to have a different role, you can use the admin user to change their role.

Users that are created directly from the CLI do not appear in Service Credentials, but you can add them.

If you manage your service through the Cloud Databases CLI plug-in, create a new user with cdb user-create. For example, to create a new user for an "example-deployment", use the following command:

ibmcloud cdb user-create example-deployment <newusername> <newpassword>

When the task finishes, retrieve the new user's connection strings with the ibmcloud cdb deployment-connections command.

etcd centralizes user data in the admin database. List all users and their roles and database permissions in the mongo shell by using the show users command.

ibmcloud cdb deployment-connections --start -u admin etcd-production
Database Password>>
etcd shell version v4.0.3
connecting to: etcd://....
....
replset:PRIMARY> use admin
switched to db admin
replset:PRIMARY> show users

Users that are created in the CLI get the same role as Service Credential users, rwall. They have access read and write access to all the keys in the database. If you need them to have a different role that you have created, you can use the root user to change their role.

Users that are created directly from the CLI do not appear in Service Credentials, but you can add them if you choose.

Managing Users and Roles through the API

If you need users to have a different role, use the admin user to change their role.

Users that are created directly from the API do not appear in Service Credentials, but you can add them.

The Foundation Endpoint that is shown on the Overview section of your service provides the base URL to access this deployment through the API. To create and manage users, use the base URL with the /users endpoint.

The command looks like:

curl -X POST 'https://api.{region}.databases.cloud.ibm.com/v4/ibm/deployments/{id}/users' \
-H "Authorization: Bearer $APIKEY" \
-H "Content-Type: application/json" \
-d '{"username":"jane_smith", "password":"newsupersecurepassword"}'

To retrieve a user's connection strings, use the base URL with the /users/{userid}/connections endpoint.

Users that are created in the API get the same role as Service Credential users, rwall. They have access read and write access to all the keys in the database. If you need them to have a different role that you have created, you can use the root user to change their role.

Users that are created directly from the API do not appear in Service Credentials, but you can add them if you choose.