vania-janet/multiturn-rag-retrieval-data huggingface dataset:
Authenticating to Watson services 

IBM Watson® services on IBM Cloud® use IBM Cloud® Identity and Access Management (IAM) for authentication. Services installed on IBM Cloud Pak® for Data support more methods. With IAM access policies, you can assign access to more than one resource from a single key. In addition, a user, service ID, and service instance can hold multiple API keys.



 Passing credentials 

To authenticate to a service through its API, pass your credentials to the API. How you authenticate can vary depending on security needs and whether the service is on IBM Cloud® or installed on IBM Cloud Pak® for Data.



 Authenticating to IBM Cloud 

IBM Cloud

You use IBM Cloud® Identity and Access Management (IAM) to make authenticated requests to public IBM Watson® services. You can pass either a bearer token in an authorization header or an API key.



* Authenticate with an IAM token.

IAM tokens are temporary security credentials that are valid for up to 60 minutes. When a token expires, you generate a new one. Tokens can be useful for temporary access to resources. For more information, see [Generating an IBM Cloud IAM token by using an API key](https://cloud.ibm.com/docs/account?topic=account-iamtoken_from_apikey).

The following curl command generates an IAM access token. Replace {apikey} with the value of your API key.

curl -X POST -header "Content-Type: application/x-www-form-urlencoded" -data "grant_type=urn:ibm:params:oauth:grant-type:apikey&apikey={apikey}" "https://iam.cloud.ibm.com/identity/token"

The response includes an access_token property. To authenticate a request to the service, replace {access_token} with the token from the response. Replace {url} with the value of the URL for your service instance, which you can find by clicking Show Credentials in the Credentials box of the Manage page for your service instance.
ibmcloud oc ibmcloud sl user list



1. Set the infrastructure API credentials to use.

ibmcloud oc credential set classic --infrastructure-username <infrastructure_API_username> --infrastructure-api-key <infrastructure_API_authentication_key> --region <region>
2. Verify that the correct credentials are set.

ibmcloud oc credential get --region <region>

Example output

Infrastructure credentials for user name user@email.com set for resource group default.



3. [Create a cluster](https://cloud.ibm.com/docs/openshift?topic=openshift-clusters). To create the cluster, the infrastructure credentials that you set for the region and resource group are used.
4. Verify that your cluster uses the infrastructure account credentials that you set.



1. Open the [IBM Cloud clusters console](https://cloud.ibm.com/kubernetes/clusters) and select your cluster.
2. In the Overview tab, look for an Infrastructure User field.
3. If you see that field, you don't use the default infrastructure credentials that come with your Pay-As-You-Go or Subscription account in this region. Instead, the region is set to use the different infrastructure account credentials that you set.









 Customizing classic infrastructure permissions 

When you assign the Super User infrastructure role to the admin or functional ID that sets the API key or whose infrastructure credentials are set, other users within the account share the API key or credentials for performing infrastructure actions. You can then control which infrastructure actions the users can perform by assigning the appropriate [IBM Cloud IAM platform access role](https://cloud.ibm.com/docs/openshift?topic=openshift-userschecking-perms). You don't need to edit the user's IBM Cloud infrastructure permissions.

Classic infrastructure permissions apply only to classic clusters.
The following steps assume that the API key stores the credentials of a service ID. If you set up your image pull secret to use an API key of an individual user, you must verify that user's IBM Cloud IAM permissions and credentials.



1. Find the service ID that API key uses for the image pull secret by reviewing the Description. The service ID that is created with the cluster is named cluster-<cluster_ID> and is used in the default Red Hat OpenShift project. If you created another service ID such as to access a different Red Hat OpenShift project or to modify IBM Cloud IAM permissions, you customized the description.

ibmcloud iam service-ids

Example output

UUID Name Created At Last Updated Description Locked
ServiceId-aa11... <service_ID_name> 2019-02-01T19:01+0000 2019-02-01T19:01+0000 ID for <cluster_name> false
ServiceId-bb22... <service_ID_name> 2019-02-01T19:01+0000 2019-02-01T19:01+0000 Service ID for IBM Cloud Container Registry in Kubernetes cluster <cluster_name> namespace <project> false
2. Verify that the service ID is assigned at least an IBM Cloud IAM Reader[service access role policy for IBM Cloud Container Registry](https://cloud.ibm.com/docs/Registry?topic=Registry-usercreate). If the service ID does not have the Reader service access role, [edit the IAM policies](https://cloud.ibm.com/docs/account?topic=account-serviceidsupdate_serviceid). If the policies are correct, continue with the next step to see if the credentials are valid.

ibmcloud iam service-policies <service_ID_name>

Example output

Policy ID: a111a111-b22b-333c-d4dd-e555555555e5
Roles: Reader
Resources:
Service Name container-registry
Service Instance
Region
Resource Type namespace
Resource <registry_namespace>
3.
IAM platform access roles 

IBM Cloud Kubernetes Service is configured to use IBM Cloud IAM Identity Service roles. IBM Cloud IAM platform access roles determine the actions that users can perform on IBM Cloud resources such as clusters, worker nodes, and Ingress application load balancers (ALBs). IBM Cloud IAM platform access roles also automatically set basic infrastructure permissions for users. To assign platform access roles, see [Granting users access to your cluster through IBM Cloud IAM](https://cloud.ibm.com/docs/containers?topic=containers-userschecking-perms).

See the IAM Policy Management [API reference](https://cloud.ibm.com/apidocs/iam-policy-managementlist-roles) for more information on managing IAM roles with the API.

Do not assign IBM Cloud IAM platform access roles at the same time as a service access role. You must assign platform and service access roles separately.



* Actions requiring no permissions: Any user in your account who runs the CLI command or makes the API call for the action sees the result, even if the user has no assigned permissions.
* Viewer actions: The Viewer platform access role includes the actions that require no permissions, plus the permissions that are shown in the Viewer tab of following table. With the Viewer role, users such as auditors or billing can see cluster details but not modify the infrastructure.
* Editor actions: The Editor platform access role includes the permissions that are granted by Viewer, plus the following. With the Editor role, users such as developers can bind services, work with Ingress resources, and set up log forwarding for their apps but can't modify the infrastructure.
* Operator actions: The Operator platform access role includes the permissions that are granted by Viewer, plus the permissions that are shown in the Operator tab of the following table. With the Operator role, users such as site reliability engineers, DevOps engineers, or cluster administrators can add worker nodes and troubleshoot infrastructure such as by reloading a worker node, but can't create or delete the cluster, change the credentials, or set up cluster-wide features like service endpoints or managed add-ons.
To do so, send the apikey keyword as the user name and the IBM Cloud API key as the password by using basic authorization HTTP header to the target service.

It is recommended that in all cases of passing an API key to a service API that you use an API key for a service ID or a user API key that is associated with a functional ID that is assigned only the level of access required to work with the particular service.

The target service API must introspect the IBM Cloud API key by using the IBM Cloud IAM service. The following graphic shows three API interactions. The IBM Cloud API key is passed to every target service’s API, so each target service must look up the IBM Cloud API key details by invoking IBM Cloud IAM.

Zoom

![Authenticating with a service API by using an API key](https://cloud.ibm.com/docs-content/v1/content/4d8c6eec891cff72b666dc24bd3211810c77fb42/account/images/APIkeyauth.svg)

Figure 2. Passing API keys to target services which then pass the API key to IAM to validate credentials

Using an IBM Cloud API key is convenient, and it makes it easy to discover new APIs and quickly try out prototypes. This method requires you to send the IBM Cloud API key to the target service‘s API in a readable format, which unnecessarily compromises the API key. Additionally, as the target service’s API must always introspect the API key, this method is less performant and therefore not recommended for production work loads.

To authenticate with a service's API by using an API key, complete the following steps:



1. First, [create an IBM Cloud API key](https://cloud.ibm.com/docs/account?topic=account-userapikeymanage-user-keys) if you have not already.
2. Send the IBM Cloud API key as defined in [RFC 7617](https://tools.ietf.org/html/rfc7617) as HTTP header “Authorization”.
IAM service roles for IBM Cloudant

 Role Description 

 Manager Includes the ability to access all endpoints and perform all administrative functions on an instance, such as creating databases, changing capacity, reading and writing data and indexes, and accessing the Dashboard. 
 Writer Includes the ability to read and write to all databases and documents, but not able to create indexes. 
 Reader Includes the ability to read all databases and documents, but not able to write new documents or create indexes. 
 Monitor Includes the ability to read monitoring endpoints, such as _active_tasks and replication _scheduler endpoints. 
 Checkpointer Includes the ability to write replication checkpointer_local documents. Required on source databases during replication. 



Manager is inclusive of all actions of Reader and Writer, and Writer is inclusive of all actions of Reader.





 IBM Cloudant actions 

The following table describes the available IAM actions and roles. For fine-grained authorization, you can use the roles of Manager, Reader, Writer, Monitor, or Checkpointer.

When you use IAM roles other than Manager, such as Reader, Writer, Monitor, or Checkpointer, you must use Use only IAM to avoid supplying users with legacy credentials that include greater access permissions.

Manager

Writer

Reader



Table 2. Actions and mapping for the Manager role

 Method Endpoint Action name 

 GET/PUT /_api/v2/db/<path:db>/_security cloudantnosqldb.sapi.db-security 
 GET /_api/v2/user/capacity/throughput cloudantnosqldb.capacity-throughput.read 
 PUT /_api/v2/user/capacity/throughput cloudantnosqldb.capacity-throughput.write 
 GET /_api/v2/user/current/throughput cloudantnosqldb.current-throughput.read 
 GET /_api/v2/user/activity_tracker/events cloudantnosqldb.activity-tracker-event-types.read 
 POST /_api/v2/user/activity_tracker/events cloudantnosqldb.activity-tracker-event-types.write
username: f6cf0c55-48ea-4908-b441-a962b27d3bb6-bluemix
apikey: XXXXX-XXXXXX_XXXXXXXXXXXXX-XXXXXXXXXXX
host: 2624fed5-e53e-41de-a85b-3c7d7636886f-bluemix.private.cloudantnosqldb.appdomain.cloud
iam_apikey_description: Auto generated apikey during resource-key operation for Instance - crn:v1:bluemix:public:cloudantnosqldb:us-south:a/b42116849bb7e2abb0841ca25d28ee4c:ee78351d-82bf-4e80-bc22-825c937fafa3::
iam_serviceid_crn: crn:v1:bluemix:public:iam-identity::a/b42116849bb7e2abb0841ca25d28ee4c::serviceid:ServiceId-53f9e2a2-cdfb-4fo0 90-b072-bfffafb68b3e
Show more







 Step 6: Listing the service credentials for your IBM Cloudant service 

The basic command format to retrieve the credentials for a service instance within IBM Cloud is shown in the following example.

ibmcloud resource service-key KEY_NAME



1. Retrieve your credentials cs20170517a (where the name for the credentials is creds_for_cs20170517a) by using a command similar to the following example.

ibmcloud resource service-key creds_for_cs20170517b
2. Review the IBM Cloud response that includes your credentials and a message similar to the following (abbreviated) example.

Retrieving service key in resource group default of account John Does's Account as john.doe@email.com...
OK
After checking, you can remove the following credentials.



* [a user from an access group](https://cloud.ibm.com/docs/account?topic=account-assign-access-resources)
* [a user's IBM Cloud IAM platform and associated RBAC permissions](https://cloud.ibm.com/docs/openshift?topic=openshift-usersremove_iam_rbac)
* [a user's custom RBAC permissions](https://cloud.ibm.com/docs/openshift?topic=openshift-usersremove_custom_rbac)
* [a user's Cloud Foundry permissions](https://cloud.ibm.com/docs/openshift?topic=openshift-usersremove_cloud_foundry)
* [a user's infrastructure permissions](https://cloud.ibm.com/docs/openshift?topic=openshift-usersremove_infra)





 Remove IBM Cloud IAM platform permissions and the associated pre-defined RBAC permissions 



1. Log in to the [IBM Cloud console](https://cloud.ibm.com/). From the menu bar, select Manage > Access (IAM).
2. Click the Users page, and then click the name of the user that you want to remove permissions from.
3. In the table entry for the user, click the Actions menu![Action menu icon](https://cloud.ibm.com/docs-content/v1/content/bce0f0917a9eea684d1b4b704ac6343a1f65f446/icons/action-menu-icon.svg)> Remove user.
4. When IBM Cloud IAM platform permissions are removed, the user's permissions are also automatically removed from the associated predefined RBAC roles. To update the RBAC roles with the changes, run ibmcloud oc cluster config.
If IBM Cloud infrastructure credentials are manually set for a region and a resource group, these credentials are used to order infrastructure for all clusters within that region in the resource group. These credentials are used to determine infrastructure permissions, even if an [IBM Cloud IAM API key](https://cloud.ibm.com/docs/openshift?topic=openshift-kubernetes-service-clics_api_key_info) exists for the resource group and region. If the user whose credentials are stored does not have the required permissions to order infrastructure, then infrastructure-related actions, such as creating a cluster or reloading a worker node can fail.

You can't set multiple credentials for the same IBM Cloud Kubernetes Service resource group and region.

Before you use this command, make sure that the user whose credentials are used has the required [IBM Cloud Kubernetes Service and IBM Cloud infrastructure permissions](https://cloud.ibm.com/docs/openshift?topic=openshift-usersusers).

ibmcloud oc credential set classic --infrastructure-api-key API_KEY --infrastructure-username USERNAME --region REGION [-q]

Minimum required permissions
: Administrator platform access role for the cluster in IBM Cloud Kubernetes Service

Command options:

--infrastructure-username USERNAME
: Required: IBM Cloud infrastructure account API username. The infrastructure API username is not the same as the IBMid. To view the infrastructure API username, see [Managing classic infrastructure API keys](https://cloud.ibm.com/docs/account?topic=account-classic_keys).

--infrastructure-api-key API_KEY
: Required: IBM Cloud infrastructure account API key. To view or generate an infrastructure API key, see [Managing classic infrastructure API keys](https://cloud.ibm.com/docs/account?topic=account-classic_keys).

--region REGION
: Specify a region in Red Hat OpenShift on IBM Cloud: jp-osa, jp-tok, au-syd, eu-de, eu-gb, us-east, or us-south.

-q
curl -X POST -header "Content-Type: application/x-www-form-urlencoded" -data "grant_type=urn:ibm:params:oauth:grant-type:apikey&apikey={apikey}" "https://iam.cloud.ibm.com/identity/token"

The response includes an access_token property. To authenticate a request to the service, replace {access_token} with the token from the response. Replace {url} with the value of the URL for your service instance, which you can find by clicking Show Credentials in the Credentials box of the Manage page for your service instance.

curl -header "Authorization: Bearer {access_token}" "{url}/v1/{method}"
* Authenticate with an IBM Cloud API key, a service ID API key, or a service-specific API key. Replace {url} with the value of the URL for your service instance, which you can find by clicking Show Credentials in the Credentials box of the Manage page for your service instance.

API keys are simple to use and don't automatically expire. Anyone with a valid key can access the resource. You can create separate API keys for different users, different applications, or to support key rotation scenarios. You can revoke API keys from the console without interfering with other API keys or the user.

The following example curl command authenticates with the API key f5sAznhrKQyvBFFaZbtF60m5tzLbqWhyALQawBg5TjRI.

curl -u "apikey:f5sAznhrKQyvBFFaZbtF60m5tzLbqWhyALQawBg5TjRI" "{url}/v1/{method}"



For testing and development, you can pass in an API key directly. However, for production use, unless you use the Watson SDKs, use an IAM token. When you pass an API key, the service looks up the API key details, so it might affect performance.
* Share the Object Storage instance itself (at platform level) with other users, enabling these users to see the credentials for themselves







 Structure of service IDS 

When you, as user of Object Storage, view the service ID credentials of a provisioned service, you will see something like what is shown in the following example:

{
"apikey": "asdf1234...",
"cos_hmac_keys": {
"access_key_id": "a1b2c3...",
"secret_access_key": "ZYX31..."
},
"endpoints": ...
}

To configure IBM Analytics Engine to work with Object Storage, you need the API key or the HMAC keys. See [API key versus HMAC keys](https://cloud.ibm.com/docs/cloud-object-storage/iam?topic=cloud-object-storage-service-credentialsservice-credentials-iam-hmac).





 Service endpoints 

As a user of Object Storage, you not only need to know the API key or the HMAC keys to configure Object Storage, but also the IBM Analytics Engine service endpoints to connect to Object Storage. See [Selecting regions and endpoints](https://cloud.ibm.com/docs/cloud-object-storage?topic=cloud-object-storage-endpoints) for help on which endpoints to use based on your Object Storage bucket type, such as regional versus cross-regional.

You can also view the endpoints across regions for your Object Storage service by selecting the service on your IBM Cloud® dashboard and clicking Endpoint in the navigation pane. Always choose the direct endpoint. Direct endpoint provide better performance and do not incur charges. An example of an endpoint for US-South Cross region is: s3.direct.us.cloud-object-storage.appdomain.cloud







 Inviting users and granting permissions 

If you, as Object Storage administrator, do not want to create and share the service credentials, you can invite users to your Object Storage account and grant them permissions by using access policies on Object Storage buckets.
After the provisioning process is finished, the instance status is Active.



Now, you can get the username and password that are necessary to log in to your instance.





 Generating credentials 



1. Log in to your IBM Cloud account.
2. Go to Resource list > Services and Software > Databases.
3. Click on your Netezza Performance Server instance.
You are now on the Service instance details page.
4. Go to the Service Credentials tab.
5. Click New Credentials.



1. Type a name to assing to your credentials.
2. Select the IAM role that was assigned to you to manage the instance.
3. Click Add.
If your credentials were generated successfully, you can view them now.



6. Expand your credential entry. The following credentials were generated:



* username: admin - Specifies a local database admin user that was created for you to access the instance.
* password: xxxx - Specifies the password that you must use when logging in to your instance as admin.
After you log in to your instance for the first time, change your admin password.





Now, you can connect to your instance as described in [Connecting to Netezza Performance Server](https://cloud.ibm.com/docs/netezza?topic=netezza-connecting-overview).
To organize a set of users and service IDs into a single entity that makes it easy for you to manage IAM permissions, use access groups. You can assign a single policy to the group instead of assigning the same access multiple times for each individual user or service ID.



 Managing access by using access groups 

To manage access groups, you must be the account owner, administrator or editor on all Identity and Access-enabled services in the account, or the assigned administrator or editor for the IAM Access Groups Service.

Use the following actions to manage IAM access groups in the IBM Cloud:



* [Creating an access group](https://cloud.ibm.com/docs/account?topic=account-groupscreate_ag).
* [Assigning access to a group](https://cloud.ibm.com/docs/account?topic=account-groupsaccess_ag).







 Managing access by assigning policies directly to users 

To manage access or assign new access to users by using IAM policies, you must be the account owner, administrator on all services in the account, or an administrator for the particular service or service instance.

Use the following actions to manage IAM policies in the IBM Cloud:



* To grant permissions to a user, see [Assigning access](https://cloud.ibm.com/docs/account?topic=account-assign-access-resourcesassign_new_access).
* To revoke permissions, see [Removing access](https://cloud.ibm.com/docs/account?topic=account-assign-access-resourcesremoving_access).
* To review a user's permissions, see [Reviewing your assigned access](https://cloud.ibm.com/docs/account?topic=account-assign-access-resourcesreview_your_access).







 IBM Cloud platform roles 

Users must be granted a platform role to allow them to view and manage the IBM Cloud Monitoring service in your account. You can grant permissions to work with all the instances in the IBM Cloud account or you can restrict access to individual instances.

The folling table identifies the platform role that you can grant a user in the IBM Cloud to run the specified platform actions: