vania-janet/multiturn-rag-retrieval-data huggingface dataset:
The Viewer role on a resource group is required for a user to create a service instance in that resource group.

The following example creates a policy for Viewer of a specific resource group:

iam user-policy-create name@example.com --roles Viewer --resource-type resource-group --resource fec6c95e6a0a44c5bcca138bfe5a1f9e

The following example creates a policy for Viewer of all resource groups in the account.

iam user-policy-create name@example.com --roles Viewer --resource-type resource-group

The following example creates a policy for Viewer of all resources in a resource group

iam user-policy-create name@example.com --roles Viewer --resource-group-name satellite-test





 Assigning access to resources by using the API 

You can assign access to an individual resource in the account or access to a list of resources in the account by calling the [IBM Cloud® Identity and Access Management (IAM) Policy Management API](https://cloud.ibm.com/apidocs/iam-policy-managementcreate-policy) as shown in the following sample request. The sample request gives Administrator role access for an instance of a service:



* Curl
* Java
* Python
* Go
* Node



curl -X POST 'https://iam.cloud.ibm.com/v1/policies' -H 'Authorization: Bearer $TOKEN' -H 'Content-Type: application/json' -d '{
"type": "access",
"description": "Administrator role for SERVICE_NAME's RESOURCE_NAME",
"subjects": [
{
"attributes":
{
"name": "iam_id",
"value": "IBMid-123453user"
}
]
}'
],
"roles":[
{
"role_id": "crn:v1:bluemix:public:iam::::role:Administrator"
}
],
"resources":[
{
"attributes":
Administrator View, create, edit, and delete custom roles<br><br>View and update IAM settings<br><br>Assign access to a group<br><br>View, create, edit, and delete access policies crn:v1:bluemix:public:iam::::role:Administrator 





 Role Management 

You can give users access to create, update, and delete custom roles for services in the account.



Table 11. Roles and example actions for the Access management service

 Roles Actions role_ID value 

 Viewer View custom roles crn:v1:bluemix:public:iam::::role:Viewer 
 Operator Not applicable 
 Editor Edit and update custom roles in an account crn:v1:bluemix:public:iam::::role:Editor 
 Administrator Create, edit, update, and delete custom roles in an account crn:v1:bluemix:public:iam::::role:Administrator 









 IAM Identity service 

You can give users access to manage service IDs and identity providers (IdPs) by using the IAM Identity service. These actions apply to service IDs and IdPs within the account that the user didn't create. All users can create service IDs. They are the administrator for those IDs, and they can create the associated API key and access policies, but only users with the operator and administrator role can create IdPs. This account management service applies to the ability to view, update, delete, and assign access to service IDs in the account created by other users.



Table 12. Roles and example actions for the IAM Identity service

 Roles Actions role_ID value 

 Viewer View IDs crn:v1:bluemix:public:iam::::role:Viewer 
 Operator Create and delete IDs and API keys<br><br>View, create, update, and delete IdPs<br><br>Update IAM account setting for service IDs and user API key creation<br><br>Delete trusted profiles crn:v1:bluemix:public:iam::::role:Operator
Enabling this setting affects only the creation of user API keys. It does not affect API keys for service IDs.



1. Create an argument in your main.tf file. The following example enables the API key creation setting by using the ibm_iam_account_settings and iam_account_settings_instance resources.
2. Defines whether or not creating platform API keys is access controlled. Supported valid values are:



* RESTRICTED - to apply access control
* NOT_RESTRICTED - to remove access control
* NOT_SET - to unset a previous set value.



resource "ibm_iam_account_settings" "iam_account_settings_instance" {
restrict_create_platform_apikey = "RESTRICTED"
}
3. Provision the resources from the main.tf file. For more information, see [Provisioning Infrastructure with Terraform](https://www.terraform.io/cli/run).



1. Run terraform plan to generate a Terraform execution plan to preview the proposed actions.

terraform plan
2. Run terraform apply to create the resources that are defined in the plan.

terraform apply





For more information, see the [Terraform documentation](https://registry.terraform.io/providers/IBM-Cloud/ibm/latest/docs/resources/iam_account_settingsrestrict_create_platform_apikey).

Now that the setting is enabled to restrict users from creating API keys, you can assign the required access to enable specific users to continue creating user API keys. Remember, the account owner is also required to be assigned this explicit access.





 Assigning access to create API keys with restrictions enabled 

If the API key creation setting is enabled, only users, including the account owner, assigned the User API key creator role on the IAM Identity Service can create API keys.

The quickest way to assign a group of users the required access for creating API keys is to create an access group and assign the group the required role.
apiconnect.user_registry_testConnection.create Test a User Registry connection 
 apiconnect.user_registry_search.create Search for users in the user registry 
 apiconnect.user_create.create Create a User object 
 apiconnect.user_clear.delete Clear the User objects 
 apiconnect.user_update.update Update the User object by name or ID 
 apiconnect.user_del.delete Delete the User object by name or ID 
 apiconnect.user_requestPasswordReset.create Send reset password link 
 apiconnect.user_resetPassword.create Reset password 
 apiconnect.user_searchAdmin.create Search for users in the admin realm 
 apiconnect.user_searchProvider.create Search for users in the provider realm 
 apiconnect.oauth2_token.create Generate a token 
 apiconnect.oauth2_redirect_post.create Authorization provider redirect endpoint 
 apiconnect.api_key_create.create Create a API Key object 
 apiconnect.api_key_del.delete Delete the API Key object by name or ID 
 apiconnect.org_setting_singletonUpdate.update Update the Organization Setting object 
 apiconnect.notification_template_updateProviderSubcollectionOrgScope.update Update the Notification Template object by name or ID 
 apiconnect.notification_template_updateCatalogSubcollectionOrgScope.update Update the Notification Template object by name or ID 
 apiconnect.notification_template_updateSpaceSubcollectionOrgScope.update Update the Notification Template object by name or ID 
 apiconnect.notification_template_updateConsumerSubcollectionOrgScope.update Update the Notification Template object by name or ID 
 apiconnect.org_update.update Update the Organization object by name or ID 
 apiconnect.org_del.delete Delete the Organization object by name or ID 
 apiconnect.org_transferOwner.create Transfer owner to an associate
The certificate CRN is listed in the side panel.









 Configuring user IDs and passcodes 

To configure authentication for VPN client users, follow these steps:



1. The VPN administrator invites the user of the VPN client to the account that the VPN server resides in.
2. The VPN administrator assigns the VPN client user an IAM permission. This permission allows this user to connect with the VPN server. For more information, see [Creating an IAM access group and granting the role to connect to the VPN server](https://cloud.ibm.com/docs/vpc?topic=vpc-create-iam-access-group).
3. The VPN client user opens the following website to generate a passcode for their user ID:

https://iam.cloud.ibm.com/identity/passcode
4. The VPN client user inputs the passcode on their openVPN client and starts the connection to the VPN server. For more information, see [Setting up a client VPN environment and connecting to a VPN server](https://cloud.ibm.com/docs/vpc?topic=vpc-vpn-client-environment-setup).
resource "ibm_iam_user_policy" "test_policy" {
ibm_id = "ibm_id@ibm.com"
roles = ["Viewer", "Editor", "Administrator"]

resources {
service = "containers-kubernetes"
resource_instance_id = "my-cluster"
}
}
2. Initialize the Terraform CLI.

terraform init
3. Create a Terraform execution plan and review the output. The Terraform execution plan summarizes all the actions that run to create the Red Hat OpenShift cluster in your account. Note the Plan section of the output. The example output states Plan: 1 to add, 0 to change, 0 to destroy because the configuration file creates one IAM user access policy.

Terraform used the selected providers to generate the following execution plan. Resource actions are
indicated with the following symbols:
+ create

Terraform will perform the following actions:

 ibm_iam_user_policy.test_policy will be created
+ resource "ibm_iam_user_policy" "test_policy" {
+ account_management = false
+ ibm_id = "ibm_id@ibm.com"
+ id = (known after apply)
+ roles = [
+ "Viewer",
+ "Editor",
+ "Administrator",
]

+ resources {
+ service = "containers-kubernetes"
}
}

Plan: 1 to add, 0 to change, 0 to destroy.
4. Apply the configuration file to create the access policy. It may take a few seconds to complete. In the output, note the policy ID number after the user's IBM email.

terraform apply

Example output:

ibm_iam_user_policy.test_policy: Creating...
ibm_iam_user_policy.test_policy: Creation complete after 2s [id=ibm_id@ibm.com/f81b161f-e1db-4084-8b28-cfcbe88fec72]
Getting a client ID and secret 

Google documentation [link](https://developers.google.com/identity/gsi/web/guides/get-google-api-clientid)

Create a project in the [Google Cloud Platform](https://cloud.google.com), configure the project to serve web clients, and obtain a client ID and secret.



1. Create a project.
2. Open [credentials page](https://console.cloud.google.com/apis/credentials) of the Google APIs console.
3. If your project doesn't have a Web application-type client ID, click Create credentials > OAuth client ID.
4. Configure your level of consent.
5. In the Authorized JavaScript Origins field, input your site's domain.
6. Click Create.
7. Copy Your Client ID and Your Client Secret







 Configuring App ID for Google authentication 

After you configure your Google project and have your client ID and secret, you can edit your service dashboard for Google authentication.



1. From the Manage page of your service dashboard, select Google and click Edit.
2. Enter the client ID and secret that you obtained from the Google Cloud Platform.
3. Authorize the App ID URL.



1. Copy the Redirect URL for Google Cloud Platform from the Google identity provider details.
2. On the credentials page of your Google project, select the client ID that you created for this integration.
3. Paste the URL from App ID into the Authorized redirect URIs field and click Save.



4. Click Save to update your Google configuration in App ID.
5. For web apps, enter a redirect URL in the Manage tab. After the authorization process completes, a user is sent to this URL. The URL must follow an http or https scheme. For a higher level of security, use an https scheme.
For example, if you create a user API key and use it for the IBM Cloud® CLI, this generates a login session. However, if you use the same API key to create a token for API calls, like [creating an IAM access token for a user or service ID](https://cloud.ibm.com/apidocs/iam-identity-token-apigettoken-apikey), this does not generate a session.

Tokens expiration settings apply only if there is no connected login session. If a login session is created, then [limits for login sessions](https://cloud.ibm.com/docs/account?topic=account-iam-work-sessions) apply. Use the following table to help you understand when each setting applies.

Users

Trusted profiles - federated users

Service IDs



Table 1. Sessions and refresh token availability - Users
When a session is created or not depends on a combination of the identity type and login type.

 Login type Sessions Refresh tokens 

 IBM Cloud® Console ![Checkmark icon](https://cloud.ibm.com/docs-content/v1/content/4d8c6eec891cff72b666dc24bd3211810c77fb42/icons/checkmark-icon.svg) ![Checkmark icon](https://cloud.ibm.com/docs-content/v1/content/4d8c6eec891cff72b666dc24bd3211810c77fb42/icons/checkmark-icon.svg) 
 IBM Cloud® CLI ![Checkmark icon](https://cloud.ibm.com/docs-content/v1/content/4d8c6eec891cff72b666dc24bd3211810c77fb42/icons/checkmark-icon.svg) !
If the console is used by multiple people or organizations, it is recommended that you create a functional email address to access your network. The use of a functional email allows you to continue to access the console even when the original administrator leaves your organization or has their email address suspended. Only a single email address can be used as the administrator contact.

To update the email address of the console administrator that was configured when the console was deployed, you must be logged in as the console administrator. Navigate to the Users tab and click Configure on the IBM ID tile. In the panel that opens, specify a new email address for the console administrator.





 Configuring node logging 

For debugging and analysis purposes, users can adjust default and custom "loggers" that control the "log level" of peer and ordering node output for particular node functions or events. When the default Information log level for a component is not sufficient for debugging, the console includes the ability to customize the logging level for the node and smart contracts.



 Before you begin 

A certificate from the peer or ordering node's TLS Certificate Authority (CA) must exist in the console wallet before you can modify a log setting on the node. You need to have the enroll ID and secret available for at least one of the CA users. (The user type does not matter.) Then, complete the following steps to generate the TLS certificate:



1. From the console, open the CA that is associated with the node. If you imported the node and its associated CA is not in your console, you need to open the CA from the console where it resides.
2. Click the actions menu icon ![menu icon](https://cloud.ibm.com/docs-content/v1/content/c5288bed34c3820e3a5251d820ee91adcd2591a3/icons/overflow-menu.svg) next to the user and then click Enroll identity.
3. On the side panel that opens, select TLS Certificate Authority from the Certificate Authority list.
4. Enter the Enroll secret that is associated with the Enroll ID for the user and click Next.
5.
Create an access policy and assign it to a user or a service ID by using the command [ibmcloud iam user-policy-create](https://cloud.ibm.com/docs/cli?topic=cli-ibmcloud_commands_iamibmcloud_iam_user_policy_create).



* This example assigns access to an individual resource in the account with the Administrator role for all instances of sample-service service:



ibmcloud iam user-policy-create name@example.com --roles Administrator --service-name sample-service



* This example assigns access to All Account Management services with the Administrator role:



ibmcloud iam service-policy-create name@example.com --roles Administrator --account-management



* This example assigns access to All Identity and Access enabled services with the Administrator role:



ibmcloud iam service-policy-create name@example.com --roles Administrator --attributes serviceType=service



* This example assigns access to All IAM Account Management services with the Administrator role:



ibmcloud iam service-policy-create name@example.com --roles Administrator --attributes service_group_id=IAM







 Assigning access within a resource group by using the CLI 

Enter the [ibmcloud user-policy-create](https://cloud.ibm.com/docs/cli?topic=cli-ibmcloud_commands_iamibmcloud_iam_user_policy_create) command to assign access to all resources in a resource group or to just one service within a resource group. This example gives name@example.comOperator role for resource group with ID dda27e49d2a1efca58083a01dfde18f6:

ibmcloud iam user-policy-create name@example.com --roles Operator --resource-type resource-group --resource dda27e49d2a1efca58083a01dfde18f6
Roles Actions 

 Viewer View access policies and custom roles 
 Operator View access policies and custom roles 
 Editor View and edit custom roles<br><br>View IAM insights, policies, and settings 
 Administrator View, create, edit, and delete custom roles<br><br>View and update IAM settings<br><br>Assign access to a group<br><br>View, create, edit, and delete access policies 





 Role Management 

You can give users access to create, update, and delete custom roles for services in the account. Child service of the IAM Access Management service.



Table 10. Roles and example actions for the Role Management service

 Roles Actions 

 Viewer View custom roles 
 Operator Not applicable 
 Editor Edit and update custom roles in an account 
 Administrator Create, edit, update, and delete custom roles in an account 









 IAM Identity service 

You can give users access to manage service IDs and identity providers (IdPs) by using the IAM Identity service. These actions apply to service IDs and IdPs within the account that the user didn't create. All users can create service IDs. They are the administrator for those IDs, and they can create the associated API key and access policies, but only users with the operator and administrator role can create IdPs. This account management service applies to the ability to view, update, delete, and assign access to service IDs in the account created by other users.



Table 11. Roles and example actions for the IAM Identity service

 Roles Actions 

 Viewer View IDs 
 Operator Create and delete IDs and API keys<br><br>View, create, update, and delete IdPs<br><br>Update IAM account setting for service IDs and user API key creation<br><br>Delete trusted profiles 
 Editor Create and update IDs and API keys<br><br>View and update IdPs<br><br>Update IAM account setting for service IDs and user API key creation<br><br>Update trusted profiles
In the output, note the policy ID number after the user's IBM email.

terraform apply

Example output:

ibm_iam_user_policy.test_policy: Creating...
ibm_iam_user_policy.test_policy: Creation complete after 2s [id=ibm_id@ibm.com/f81b161f-e1db-4084-8b28-cfcbe88fec72]
5. Verify that the IAM access policy was successfully created by running the command and searching for the policy ID you previously noted.

ibmcloud iam user-policies ibm_id@ibm.com

Example output:

Policy ID: f81b161f-e1db-4084-8b28-cfcbe88fec72
Roles: Viewer, Editor, Administrator
Resources:
Service Name containers-kubernetes
Service Instance my-cluster
However, you must get application approval from a Box administrator.
* For both application access levels, specify the following settings:
* Choose the following scopes:



* Read all folders stored in Box
* Write all folders stored in Box
* Manage Users



For apps with Enterprise access only: Add this extra scope:



* Manage Enterprise Properties



* Enable the following advanced features:



* Make API calls using the as-user header
* Generate User Access Tokens





* Get the custom app authorized by an administrator.

For more information, see [App approval](https://developer.box.com/guides/authorization/custom-app-approval/) in the Box Developer Documentation.
* After the app is created, authorized, and authentication is configured, download the app settings as a JSON file from the dev console.

You provide the following information from this file when it is requested later:



* client_id
* enterprise_id
* client_secret
* public_key_id
* private_key
* passphrase









 Connecting to the Box data source 

From your Discovery project, complete the following steps:



1. From the navigation pane, choose Manage collections.
2. Click New collection.
3. Click Box, and then click Next.
4. Refer to the values from the Box app settings JSON file that you downloaded during the previous procedure to complete the following fields:

Client ID
: The private key that you specify when you configure your Box app.

Client Secret
: The client secret that you specify when you configure your Box app.

Enterprise ID
: The enterprise ID of the Box account.

Public Key ID
: The public key ID that Box generates.

Private Key
: A part of the key pair that is generated to interact with the Box website.

Passphrase
: The passphrase that is required to decrypt the private key if the private key is an encrypted file.
5. Click Next.
6. Name the collection.
7.
You can use any user on your deployment with either endpoint (if both exist on your deployment).

curl -X GET -H "Authorization: Bearer $APIKEY" 'https://api.{region}.databases.cloud.ibm.com/v4/ibm/deployments/{id}/users/{userid}/connections/{endpoint_type}'





 More Users and Connection Strings 

Access to your Databases for Elasticsearch deployment is not limited to the admin user. You can create users by using the Service Credentials panel, the IBM CLI, or through the IBM Cloud Databases API.

All users on your deployment can use the connection strings, including connection strings for either public or private endpoints.



 Creating Users From the UI 



1. Navigate to the service dashboard for your service.
2. Click Service Credentials to open the Service Credentials panel.
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 using the specified endpoint. Use of the endpoint is not enforced as it 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 Elasticsearch 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 Users From the CLI 

If you manage your service through the IBM Cloud CLI and the [cloud databases plug-in](https://cloud.ibm.com/docs/cli?topic=cli-install-ibmcloud-cli), you can create a new user with cdb user-create. For example, to create a new user for an "example-deployment", use the following command.
On the API keys page, you can create, edit, or delete IBM Cloud API keys for yourself, and you can manage all [classic infrastructure API keys](https://cloud.ibm.com/docs/account?topic=account-classic_keys) for users that you are an ancestor of in the user hierarchy. In addition, if you are the account owner or a user assigned the required access to manage other user's API keys in the account, you can use the View filter to list and manage those API keys too.



Table 1. Required access for API key management on the API keys page

 Filter Options Displayed API Keys Required Access Allowed Actions 

 My IBM Cloud API keys Your IBM Cloud API keys No access required View, create, edit, delete 
 All user IBM Cloud API keys All IBM Cloud API keys created by all users in the account Administrator role on IAM Identity service View, edit, and delete 







 Creating an API key 

As an IBM Cloud user you might want to use an API key when you enable a program or script without distributing your password to the script. A benefit of using an API key can be that a user or organization can create several API keys for different programs and the API keys can be deleted independently if compromised without interfering with other API keys or even the user. You can create up to 20 API keys.

To create an API key for your user identity in the UI, complete the following steps:



1. In the IBM Cloud console, go to Manage > Access (IAM) > API keys.
2. Click Create an IBM Cloud API key.
3. Enter a name and description for your API key.
4. Click Create.
5. Then, click Show to display the API key. Or, click Copy to copy and save it for later, or click Download.



For security reasons, the API key is only available to be copied or downloaded at the time of creation. If the API key is lost, you must create a new API key.





 Creating an API key by using the CLI 

To create an API key by using the CLI, use the following command:



1.