vania-janet/multiturn-rag-retrieval-data huggingface dataset:
Controlling access through IAM 

IBM Cloud® Identity and Access Management (IAM) enables you to securely authenticate users and consistently control access to all cloud resources in the IBM Cloud. You grant permissions through policies that you define on the IBM Cloud Monitoring service in the account.

Users in an account must be assigned a platform role to manage instances and to launch the monitoring UI from the IBM Cloud. In addition, users must have a service role that defines the permissions to work with IBM Cloud Monitoring.

The policy determines the actions the user can perform within the context of the selected service or instance. The actions are customized and defined with operations that are allowed to be performed on the service. The actions are then mapped to IAM user roles.

Policies enable access to be granted at different levels. Some of the options include the following:



* Access to all IAM-enabled services in your account
* Access across all instances of the service in a single region in your account
* Access to an individual service instance in your account
* Access to all instances of the service within the context of a resource group
* Access to all instances of the service in a single region within the context of a resource group
* Access to all IAM-enabled services within the context of a resource group



Roles define the actions that a user or serviceID can run. There are different types of roles in the IBM Cloud:



* Platform management roles enables users to perform tasks on service resources at the platform level, for example assigning user access for the service, creating or deleting service IDs, creating instances, assigning policies for your service to other users, and binding instances to applications.
* Service access roles enables users to be assigned varying levels of permission when calling the service's API or running actions in the monitoring UI.



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.
* UI
* API
* Terraform







 Adding and viewing credentials 

You can generate a new set of credentials for times when you want to manually connect an app or external consumer to an IBM Cloud® service. For example, if you're trying to bind an AWS app to a Watson service, you need to generate a new credential that can be used to bind them together. After your credential is created, you can [manually add](https://cloud.ibm.com/docs/apps?topic=apps-credentials_overview) it to your IBM Cloud app or other [external consumer](https://cloud.ibm.com/docs/account?topic=account-externalapp) to connect your service.

To manually add credentials to your apps, refer to the documentation for the type of app or compute option that you are using.



 Adding a credential when binding an IAM-enabled service 

Services that are managed by IBM Cloud Identity and Access Management (IAM) can generate a resource key, also known as a credential. Credentials are service-specific and vary based on how each service defines the credentials they need to generate. A credential might contain a user name, password, host name, port, and a URL.

However, while the contents of each credential is unique to the service that generates it, all services managed by IAM require that new credentials include an IAM Service access role. Some services might generate more data that requires parameters to be passed in. For example, a service might require you to input a language parameter to set the default language that is returned in the resource key that is generated.

Complete the following steps to add a credential to a service that is managed by IAM:



1. From the Resource list page, select the name of the service to open the service details page. Then, select the Credentials tab, and click New Credential.
2. From the Add New Credential dialog, provide a Name.
3. Specify the role. This value sets the IAM service access role.
Setting up Secrets Manager in your Kubernetes Service cluster 

When you integrate IBM Cloud Secrets Manager with your IBM Cloud Kubernetes Service cluster, you can centrally manage Ingress subdomain certificates and other secrets.



 About Secrets Manager 

With Secrets Manager, you can use a single service to manage your secrets and control who has access to them. A Secrets Manager instance is not automatically provisioned in your cluster. However, you can use a single Secrets Manager instance across multiple clusters, and a single cluster can have more than one instance.



 What functionality can I gain with Secrets Manager? 

With Secrets Manager, you can:



* Create managed Kubernetes secrets with Ingress TLS certificates included.
* Create Kubernetes secrets of any type by using the CRN of any Secrets Manager instance you own.
* Automatically update your secrets in your cluster on a regular basis.
* Track the expiration dates of your certificates from the IBM Cloud console.
* Control who has access to your secrets by creating secret groups for approved users.



Note that to have your secrets automatically updated, you must register at least one Secrets Manager instance to your cluster. For more information, see [Registering your Secrets Manager instance to your cluster](https://cloud.ibm.com/docs/containers?topic=containers-secrets-mgrsecrets-mgr_setup_register).







 Secrets Manager FAQ 

Keep the following points in mind when using Secrets Manager.

What types of secrets are supported with Secrets Manager?
: Secrets Manager supports IAM credentials, key-value secrets, user credentials, arbitrary secrets, and Kubernetes secrets. For Kubernetes secrets, Secrets Manager supports both TLS and non-TLS (Opaque) secret types. With TLS secrets, you can specify one certificate CRN. With non-TLS secrets, you can specify multiple fields to pull non-certificate secrets. If you do not specify a secret type when you create a secret, TLS is applied by default. For more information on supported secrets, see [Working with secrets of different types](https://cloud.ibm.com/docs/secrets-manager?topic=secrets-manager-what-is-secretsecret-types).
The CRN of the IBM Cloud Secret Manager instance.

--is-default
: Optional. Include this option to also set the registered instance as the default Secrets Manager instance where all Ingress subdomain certificates are stored. If another instance is already set as default, it is removed. Note that you must manually update any certificates or secrets to upload them to the new default instance. Otherwise, they are uploaded at the next scheduled update time for the secret.

-q
: Optional: Do not show the message of the day or update reminders.

--secret-group GROUP
: Secret group ID of the IBM Cloud Secret Manager instance where the secrets are persisted. To get a secret group ID, see the [Secrets Manager CLI reference](https://cloud.ibm.com/docs/secrets-manager-cli-plugin?topic=secrets-manager-cli-plugin-secrets-manager-clisecrets-manager-cli-secret-groups-command).

Example:

ibmcloud oc ingress instance register --cluster my-cluster --crn crn:v1:staging:public:secrets-manager:eu-gb:a/1a11a1a111aa11aa111aa1a1111aa1a1:1aaa1a1a-aaaa-11aa-1a11-a11aaa1a11a1:secret:a1a11a11-111a-11a1-aa11-11aaa1a11a11 --secret-group 90e059dd-d04e-a32b-010f-4d303b9050b8





 ibmcloud oc ingress instance unregister 

Virtual Private Cloud

Classic infrastructure

Remove a Secrets Manager instance from a cluster.

ibmcloud oc ingress instance unregister --cluster CLUSTER --name NAME [-q]

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

Command options:

--c, --cluster CLUSTER
: Required. The name or ID of the cluster.

--name
: Required. The name of the Secrets Manager instance to remove.
Select Resources based on selected attributes.
5. In the Service instance field, select your CIS instance.
6. In the Roles and actions section, select the Manager role. If you want to grant the service ID the ability to access the CIS instance from the Resource list in the IBM Cloud console, you can also assign the Viewer platform role.
7. Click Review > Add > Assign to complete the access assignment.



5. Complete the steps to [add a DNS configuration](https://cloud.ibm.com/docs/secrets-manager?topic=secrets-manager-add-dns-provider) to your Secrets Manager instance.









 Granting service access to classic infrastructure 

If you manage domains by using classic infrastructure, you must grant service access to its DNS service so that Secrets Manager can validate the ownership of your domains. You need your classic infrastructure account credentials before you can grant access.

To obtain your classic infrastructure username and API key, you can use the Access (IAM) section of the console.

You can view and access your classic infrastructure credentials from the Access (IAM) section of the console only if you are a classic infrastructure user. If you do not have classic infrastructure access, the VPN username and classic infrastructure API key fields do not display on the page. For more information, see [Managing classic infrastructure access](https://cloud.ibm.com/docs/account?topic=account-mngclassicinfra).

Zoom

![The figure shows a simplified IAM dashboard with numbered steps for viewing your classic infrastructure username and API key. The steps are described in the following text.](https://cloud.ibm.com/docs-content/v1/content/991f60ddbe3ab0a9aa69481a07a0a73b359fa329/secrets-manager/images/classic-infra-creds.svg)

Figure 2. Viewing your classic infrastructure username and API key



1. In the console, go to Manage > Access (IAM) > Users, then select the user's name.
2.
--tls-secret, --secret, --tls
: Specify a TLS secret that contains the certificate including all its intermediate certificates and the corresponding private key for the domain mapping. The certificate must be signed by a trusted, public certificate authority (CA). Self-signed certificates are not supported. This value is optional.





 Example 

The following example updates the www.example.com domain mapping to use mytlssecret2 instead of mytlssecret.

ibmcloud ce domainmapping update --domain-name www.example.com --tls-secret mytlssecret2





 Example output 

Updating domainmapping 'www.example.com'...









 Job commands 

A job runs one or more instances of your executable code. Unlike applications, which handle HTTP requests, jobs are designed to run one time and exit. When you create a job, you can specify workload configuration information that is used each time that the job is run. Use job commands to create a configuration for your job.

You must be within the context of a [project](https://cloud.ibm.com/docs/cli?topic=cli-clicli-project) before you use job commands.

For more information about working with jobs, see [Running jobs](https://cloud.ibm.com/docs/codeengine?topic=codeengine-job-plan).

To see CLI help for the job commands, run ibmcloud ce job -h.



 ibmcloud ce job bind 

Bind an IBM Cloud service instance to a job.

ibmcloud ce job bind --name JOB_NAME (--service-instance SI_NAME | --service-instance-id SI_ID) [--no-wait] [--prefix PREFIX] [--quiet] [--role ROLE] [--service-credential SERVICE_CREDENTIAL] [--wait] [--wait-timeout WAIT_TIMEOUT]



 Command Options 

--name, -n
: The name of the job to bind. This value is required.

--no-wait, --nw
"iam_apikey_description": "Auto-generated for key abcdabcd-abcd-4d8c-78cf-abcdabcdabcd",
"iam_apikey_name": "my-object-storage-codeengine-credential",
"iam_role_crn": "crn:v1:bluemix:public:iam::::serviceRole:Writer",
"iam_serviceid_crn": "crn:v1:bluemix:public:iam-identity::a/1176a104ad4241e6b0aa82ed0b60c15c::serviceid:ServiceId-abcdabcd-7ae8-abcd-a219-abcdabcdabcd",
"resource_instance_id": "crn:v1:bluemix:public:cloud-object-storage:global:a/1176a104ac4241e6b0cb82ed0b60c15c:abcdabcd-abcd-4777-abcd-d330a450c85b::"
}

To bind a service instance to your Code Engine workload, you must provision an instance of the service first. Then, use the Code Engine console or the CLI to bind your app or job to your IBM Cloud service instance.

When you bind a service instance to a Code Engine workload, Code Engine uses a service access secret to store the credential of the specified IBM Cloud service instance. This type of secret is the key mechanism in a service binding that connects the IBM Cloud service instance to a particular Code Engine app or job. Code Engine creates and manages this secret for you.

What types of services can I bind?
: You can add any type of IBM Cloud service that is enabled for IBM Cloud Identity and Access Management (IAM) and that uses service credentials to your application or job. To find a list of supported IBM Cloud services, see the [IBM Cloud catalog](https://cloud.ibm.com/catalog).

I already have service credentials for an IBM Cloud service instance.
"iss": "https://iam.cloud.ibm.com/identity",
"grant_type": "urn:ibm:params:oauth:grant-type:apikey",
"scope": "openid <your serviceName>",
"client_id": "bx",
"acr": 1,
"amr": [
"pwd"
]
}
Show more

The scope field value refers to the service programmatic name.





 Calling IAM to check user authorization 

After you decode the user's access token, call IAM to check whether the user is authorized to access the service dashboard by using the iam_id and scope fields and values from the previous step.

Review the following example of an IAM call:

curl -X POST -H "Accept: application/json" -H "Content-Type: application/json" -H "Authorization: Bearer <access token from step 1>" -d '[ { "subject" : { "attributes": { "id": "<iam_id field value from user's token>", "scope": "<scope field value from user's token>" } }, "resource" : { "crn" : "<resource instance CRN>" }, action : <your service name> + ".dashboard.view" } ]' https://iam.cloud.ibm.com/v2/authz
Show more

The crn field value refers to the service instance ID.









 IAM token scoping for third-party service providers 

User access tokens that are created with your client ID can be used to access only your service APIs. Requests to other IBM Cloud APIs that use this token are denied access, even if the user has an appropriate policy configured.

As part of third-party integration, token scoping is being used to ensure that tokens have the minimal access scope that is needed to accomplish the user's goals. To facilitate this, IAM tokens access is based on the client ID that created the token.
-H "Authorization: Bearer {iam_token}" -H "Accept: application/json" --H "Content-Type: application/merge-patch+json" -d '{ "version_custom_metadata": { "version_special_id" : "someString" } }' "https://{instance_ID}.{region}.secrets-manager.appdomain.cloud/api/v2/secrets/{id}/versions/{version_id}/metadata"

A successful response returns metadata details about each secret version.

{
"alias": "current",
"created_at": "2022-06-27T11:58:15Z",
"created_by": "iam-ServiceId-e4a2f0a4-3c76-4bef-b1f2-fbeae11c0f21",
"expiration_date": "2023-10-05T11:49:42Z",
"id": "bc656587-8fda-4d05-9ad8-b1de1ec7e712",
"payload_available": true,
"secret_group_id": "67d025e1-0248-418f-83ba-deb0ebfb9b4a",
"secret_id": "67d025e1-0248-418f-83ba-deb0ebfb9b4a",
"secret_name": "example-arbitrary-secret",
"secret_type": "arbitrary",
"version_custom_metadata": {
"custom_version_key": "custom_version_value"
}
}

The downloaded property indicates whether the data for each secret version was already read or accessed.
"serial_number": "1:2:3:4"
},
],
"source_instance_api_private_url": "https://<instance_id>.private.<region>.secrets-manager.appdomain.cloud/api",
"source_instance_api_public_url": "https://<instance_id>.<region>.secrets-manager.appdomain.cloud/api",
"source_instance_crn": "crn:v1:bluemix:public:secrets-manager:<region>:a/<account_id>:<instance_id>::",
"source_instance_dashboard_url": "https://cloud.ibm.com/services/secrets-manager/crn%3Av1%3Abluemix%3Apublic%3Asecrets-manager%3A<region>%3Aa%2Fa6cc9f5f21f34323a4175c1117638b40%3A<instance_id>%3A%3A",
"source_service": "SecretsManager"
}

Review following table for more information about event notification properties.



Table 3. Properties in an event notification payload

 Property Description 

 event_sub_type The subtype that corresponds with the [type of event](https://cloud.ibm.com/docs/secrets-manager?topic=secrets-manager-event-notificationsevent-notifications-list) that triggered a notification. 
 event_type The [type of event](https://cloud.ibm.com/docs/secrets-manager?topic=secrets-manager-event-notificationsevent-notifications-list) that triggered a notification. 
 secret_type The type of secret that is associated with the event.<br><br>Possible values include: imported_cert, private_cert, public_cert 
 secrets[] A list of objects that contain the metadata properties of a secret that is associated with the event.
* UI
* CLI
* API
* Terraform







 Adding certificate templates 

A certificate template helps you to define the parameters to apply to the private certificates that you create in your IBM Cloud® Secrets Manager service instance. By using a certificate template, you can include parameters to control certificate common names, alternate names, the key uses that they are valid for, and more.

You can define up to 10 certificate templates per instance. To view a list of templates that are available for a specific certificate authority, go to the Secrets engines > Private certificates page in the Secrets Manager UI.

You can define up to 10 certificate templates per instance. To obtain a list of templates that are available for a specific certificate authority, you can use the [List configurations](https://cloud.ibm.com/apidocs/secrets-manager/secrets-manager-v2get-secret-config-element) API.



 Specifying allowed domains for generated certificates 

You can specify the domains that are allowed for the certificates that you generate.



* Use the Domains settings section to add the domains that the template allows. Then, the list is used with the Allow bare domain and Allow subdomains options to determine the type of matching between these domains and the domains for which clients can request certificates.
* Enable the Allow bare domains option to specify whether clients can request certificates that match the domains that the template allows.
* Enable the Allow subdomains option to indicate whether clients can request certificates that match subdomains of the domains that this template allows. Wildcard subdomains are included in this option.







 Before you begin 

Before you get started, be sure that you have the required level of access. To manage engine configurations for your instance, you need the [Manager service role or higher](https://cloud.ibm.com/docs/secrets-manager?topic=secrets-manager-iam).





 Adding a certificate template in the UI 

[After you create an intermediate certificate authority](https://cloud.ibm.com/docs/secrets-manager?topic=secrets-manager-intermediate-certificate-authorities) for your instance, you can create a certificate template by using the Secrets Manager UI.



1.
Auditing events for IAM 

As a security officer, auditor, or manager, you can use the IBM Cloud Activity Tracker service to track how users and applications interact with the IBM Cloud® Identity and Access Management (IAM) service in IBM Cloud.

IAM enables you to securely authenticate users for both platform services and control access to resources consistently across IBM Cloud. [Learn more](https://cloud.ibm.com/docs/account?topic=account-iamoverview).

The IBM Cloud Activity Tracker service records user-initiated activities that change the state of a service in IBM Cloud. To get started monitoring your user's actions, see [IBM Cloud Activity Tracker](https://cloud.ibm.com/docs/services/activity-tracker?topic=activity-tracker-getting-startedgetting-started). An initiator can be a user, a service, or an application.



 Access groups events 



 Account events 

The following table lists the actions that generate an event:



Table 1. Events that are generated for access groups

 Action Description 

 iam-groups.account-settings.read An event is generated when an initiator views the account settings for the access groups service. 
 iam-groups.account-settings.update An event is generated when an initiator updates their account settings for the access groups service. 







 Access groups events 

The following table lists the actions that generate an event:



Table 2. Events that are generated for access groups

 Action Description 

 iam-groups.group.create An event is generated when an initiator creates an access group. 
 iam-groups.group.read An event is generated when an initiator views an access group. 
 iam-groups.group.update An event is generated when an initiator updates a group name or a description. 
 iam-groups.group.delete An event is generated when an initiator deletes an access group. 
 iam-groups.groups.list An event is generated when an initiator views the access groups. 







 Members events 

The following table lists the actions that generate an event:



Table 3. Events that are generated for access groups

 Action Description
Managing access with IAM 

IBM Cloud® Identity and Access Management (IAM) enables you to securely authenticate users and control access to all cloud resources consistently in the IBM Cloud. Access to IBM Cloud Activity Tracker service instances for users in your account is controlled by IBM Cloud Identity and Access Management (IAM).

The access policy that you assign users in your account determines what actions a user can perform within the context of the service or specific instance that you select. The allowable actions are customized and defined by Activity Tracker as operations that are allowed to be performed on the service. An action is mapped to an IAM platform or service role that you can assign to a user.

For more information about the steps to assign IAM access, see [Managing access to resources](https://cloud.ibm.com/docs/account?topic=account-assign-access-resources).



* Use logdnaat for Activity Tracker hosted event search offerings.
* When you assign policies to users, use IBM Cloud Activity Tracker for the service name in the UI for Activity Tracker hosted event search offerings.



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 per individual user or service ID.



 Managing access by using access groups 

To manage access or assign new access for users by using 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.

Choose any of the following actions to manage 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 for 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.