vania-janet/multiturn-rag-retrieval-data huggingface dataset:
"https://iam.cloud.ibm.com/identity/token" |jq -r '(.token_type + " " + .access_token)'

To view the IAM token, run echo $iam_token. The result should look like this:

Bearer <your token>

The Authorization header expects the token to begin with "Bearer". If the result doesn't include "Bearer", update the iam_token variable to include it. These examples assume that "Bearer" is included in the iam_token.

You must repeat the preceding step to refresh your IAM token every hour because the token expires.





 Step 3: Store the API endpoint as a variable 

Run the following command to store the API endpoint in a variable so it can be reused later in your session.

Public endpoint:

vpc_api_endpoint="https://us-south.iaas.cloud.ibm.com"

Virtual private endpoint:

vpc_api_endpoint="https://us-south.private.iaas.cloud.ibm.com"

To verify that this variable was saved, run echo $vpc_api_endpoint and make sure that the response is not empty.

For supported endpoint regions, see [Endpoints available](https://cloud.ibm.com/docs/vpc?topic=vpc-service-endpoints-for-vpc).





 Step 4: Store the API version as a variable 

Every API request must include the version parameter, in the format YYYY-MM-DD. Run the following command to store the version date in a variable so it can be reused in your session. For more information about setting the version parameter, see Versioning in the [Virtual Private Cloud API](https://cloud.ibm.com/apidocs/vpcapi-versioning).

api_version="2019-09-30"

To verify that this variable was saved, run echo $api_version and make sure that the response is not empty.





 Step 5: Verify that you have API access
Enabling and managing Identity and Access Management 

You can optionally enable IBM Cloud® Identity and Access Management (IAM) for your VMware Cloud Director Organization. For new organizations, IAM is enabled by default. For existing organizations, you can set or reset the IAM enablement from the virtual data center site details page.



 Before you begin 

Review roles and assign resource access for IBM Cloud for VMware Solutions Shared service instances. For more information, see [Managing IAM access for VMware Solutions](https://cloud.ibm.com/docs/vmwaresolutions?topic=vmwaresolutions-iam) and [Roles and permissions for VMware Cloud Director](https://cloud.ibm.com/docs/vmwaresolutions?topic=vmwaresolutions-iam_vcd&interface=ui).





 Responsibilities when you use Identity and Access Management 

Review the following considerations to understand your responsibilities and IBM responsibilities for managing IAM.



 IBM responsibilities 



* Configure the IAM integration with the VMware Cloud Director console by using OpenID Connect (OIDC) for new site deployments.
* Populate the initial roles and permissions in VMware Cloud Director console that map to the IAM roles. For more information, see [Roles and permissions for VMware Cloud Director](https://cloud.ibm.com/docs/vmwaresolutions?topic=vmwaresolutions-iam_vcd&interface=ui).







 Your responsibilities 



* Maintain and manage the IAM integration with VMware Cloud Director as desired.
* Remove or disconnect the IAM integration with VMware Cloud Director if desired.
* Customize the populated roles and permissions in VMware Cloud Director as desired.
* Update the roles and permissions, including the IBM populated ones, as new permissions are provided in VMware Cloud Director.









 Procedure to enable IAM 

Enable IAM for existing organizations or reset the IAM integration if necessary.



1. From the IBM Cloud for VMware Solutions console, click Resources > VMware Shared from the left navigation pane.
2.
When you use IAM access tokens, you authenticate before you send a request to Discovery.



1. Get an API key from IBM Cloud. Use that key to generate an IAM access token. For more information, see [Authenticating to Watson services](https://cloud.ibm.com/docs/watson?topic=watson-iam).
2. Pass the IAM access token to Discovery by using the Authorization header. In the header, indicate that the access token is a Bearer token by specifying Authorization: Bearer {access_token}.

The following simple cURL example uses an access token:

curl -X GET
--header "Authorization: Bearer eyJhbGciOiJIUz......sgrKIi8hdFs"
"{url}/v1/environments?version=2017-11-07"

Replace {url} with your URL.







 Refreshing an IAM access token 

IAM access tokens that you generate have the following structure. You use the value of the access_token field to make an authenticated request to the service.

{
"access_token": "eyJhbGciOiJIUz......sgrKIi8hdFs",
"refresh_token": "SPrXw5tBE3......KBQ+luWQVY=",
"token_type": "Bearer",
"expires_in": 3600,
"expiration": 1473188353
}

Access tokens have a limited time to live. The expires_in field indicates how long the token lasts, in this case one hour. The expiration field shows when the token expires as a UNIX timestamp that specifies the number of seconds since January 1, 1970 (midnight UTC/GMT).

In your application, check the access token's expiration time before you use it to make an authenticated request. If it is expired, you must refresh the access token before you can use it. You use the value of the refresh_token field to refresh the access token.
$ curl -X POST "https://<region>.kms.cloud.ibm.com/api/v2/keys/<keyID_or_alias>/actions/sync" -H "authorization: Bearer <IAM_token>" -H "bluemix-instance: <instance_ID>"

Replace the variables in the example request according to the following table.





Table 1. Describes the variables that are needed to initiate a re-notification of a key lifecycle event

 Variable Description 

 region Required. The region abbreviation, such as us-south or eu-gb, that represents the geographic area where your Key Protect instance resides. <br> <br>For more information, see Regional service endpoints](/docs/key-protect?topic=key-protect-regions#service-endpoints). 
 keyID_or_alias Required. The identifier or alias for the root key that is associated with the cloud resources that you want to view. <br> <br>For more information, see [View Keys](https://cloud.ibm.com/docs/key-protect?topic=key-protect-view-keys). 
 IAM_token Required. Your IBM Cloud access token. Include the full contents of the IAM token, including the Bearer value, in the curl request. <br> <br>For more information, see [Retrieving an access token](https://cloud.ibm.com/docs/key-protect?topic=key-protect-retrieve-access-token). 
 instance_ID Required. The unique identifier that is assigned to your Key Protect service instance. <br> <br>For more information, see [Retrieving an instance ID](https://cloud.ibm.com/docs/key-protect?topic=key-protect-retrieve-instance-ID). 



A successful GET api/v2/keys/<keyID_or_alias>/actions/sync request returns an HTTP 204 No Content response, which indicates that the IBM cloud service that is associated with the specified key has been notified.





 Synchronization considerations
IAM access concepts 

The concept of access management consists of a few interrelated components, including users, service IDs, access groups, trusted profiles, resources, policies, roles, actions, and the IBM Cloud IAM control system, which allows users to take actions on resources within an account.

IBM Cloud IAM follows an [eventually consistent](https://en.wikipedia.org/wiki/Eventual_consistency) pattern that is common to many cloud-native services. As a result, IAM remains highly available and performant across multiple global regions. Changes that are made to IAM access policies, authorizations, service IDs, API keys, access groups, trusted profiles, resource groups, users, or any other access controls are recorded and propagated across all IAM components and IAM-enabled services worldwide. Access changes might not take effect until the propagation process is complete.



 Access groups 

A group of users and service IDs can be organized so that the same access can be assigned to all members within the group by using one or more policies. With access groups, you can streamline the access assignment process so that you can manage a smaller number of policies and reduce the number of policies in an account, which in turn increases performance. Access groups allow you to grant and revoke access by simply adding or removing users or service IDs in the access group. After your groups are set up, you can start assigning policies by selecting an access group as the subject of the policy. For more information, see [Access groups for streamlined access management](https://cloud.ibm.com/docs/account?topic=account-access-management-overviewaccess-groups-quick-access).





 Trusted profiles 

With trusted profiles, you manage the identities of your users within your own corporate directory. And, you can centrally manage the access lifecycle to multiple IBM Cloud accounts and assets for federated users without the need to configure access policies for each entity within each account. You don't need to invite users to your account to give them to access your IBM Cloud resources.

You can also define fine-grained authorization for all applications that are running in a compute resource without creating service IDs or managing the API key lifecycle for applications.
* CLI
* API







 Retrieving an access token 

Get started with the Hyper Protect Crypto Services key management service API by authenticating your requests to the service with an IBM Cloud® Identity and Access Management (IAM) access token.

An access token is a temporary credential that expires after 1 hour. After the acquired token expires, you must generate a new token to continue calling IBM Cloud or service APIs. To maintain access to the service, regenerate the access token for your API key regularly.



 Retrieving an access token with the CLI 

You can use the [IBM Cloud CLI](https://cloud.ibm.com/docs/cli?topic=cli-getting-started) to quickly generate your personal Cloud IAM access token.



1. Log in to IBM Cloud with the [IBM Cloud CLI](https://cloud.ibm.com/docs/cli?topic=cli-getting-started).

ibmcloud login

If the login fails, run the ibmcloud login --sso command to try again. The --sso parameter is required when you log in with a federated ID. If this option is used, go to the link listed in the CLI output to generate a one-time passcode.
2. Select the region and resource group where you would like to create a Hyper Protect Crypto Services service instance. You can use the following command to set your target region and resource group.

ibmcloud target -r <region_name> -g <resource_group_name>
3. Run the following command to retrieve your Cloud IAM access token.

ibmcloud iam oauth-tokens

The following truncated example shows a retrieved IAM token.

IAM token: Bearer eyJraWQiOiIyM...







 Retrieving an access token with the API 

You can also retrieve your access token programmatically by using an [API key](https://cloud.ibm.com/docs/account?topic=account-manapikey), and then exchanging your API key for an IBM Cloud IAM token.
IAM access concepts 

The concept of access management consists of a few interrelated components, including users, service IDs, access groups, trusted profiles, resources, policies, roles, actions, and the IBM Cloud IAM control system, which allows users to take actions on resources within an account.

IBM Cloud IAM follows an [eventually consistent](https://en.wikipedia.org/wiki/Eventual_consistency) pattern that is common to many cloud-native services. As a result, IAM remains highly available and performant across multiple global regions. Changes that are made to IAM access policies, authorizations, service IDs, API keys, access groups, trusted profiles, resource groups, users, or any other access controls are recorded and propagated across all IAM components and IAM-enabled services worldwide. Access changes might not take effect until the propagation process is complete.



 Access groups 

A group of users and service IDs can be organized so that the same access can be assigned to all members within the group by using one or more policies. With access groups, you can streamline the access assignment process so that you can manage a smaller number of policies and reduce the number of policies in an account, which in turn increases performance. Access groups allow you to grant and revoke access by simply adding or removing users or service IDs in the access group. After your groups are set up, you can start assigning policies by selecting an access group as the subject of the policy. For more information, see [Access groups for streamlined access management](https://cloud.ibm.com/docs/secure-enterprise?topic=secure-enterprise-access-management-overviewaccess-groups-quick-access).





 Trusted profiles 

With trusted profiles, you manage the identities of your users within your own corporate directory. And, you can centrally manage the access lifecycle to multiple IBM Cloud accounts and assets for federated users without the need to configure access policies for each entity within each account. You don't need to invite users to your account to give them to access your IBM Cloud resources.

You can also define fine-grained authorization for all applications that are running in a compute resource without creating service IDs or managing the API key lifecycle for applications.
Created At: Fri Nov 1 17:40:13 UTC 2019
State: active
Credentials:
apikey: uYowcbhwgOMzO61AJTHzCsPMmG0lB69pzr6helVlE6JF
host: 37c53a06-5193-23f3-b681-7c8b76ce7qaa-bluemix.cloudantnosqldb.appdomain.cloud
iam_apikey_description: Auto-generated for key a3db65f4-7fe9-4ddb-bf67-e588a278753f
iam_apikey_name: Cloudant-cred
iam_role_crn: crn:v1:bluemix:public:iam::::serviceRole:Manager
iam_serviceid_crn: crn:v1:bluemix:public:iam-identity::a/6ef045fd2b43266cfe8e6388dd2ec098::serviceid:ServiceId-132fe428-7a4f-43bf-8c50-b8a169c97988
password: e2dbc589632a0651ae44ee3920f8cdb02bdcb68e1909b6314c42f5b0d39c043a
port: 423
url: https://37c53a06-5193-23f3-b681-7c8b76ce7qaa-bluemix:e2ddc589631a0651af44ee3920f9bab02bdcb68e1908b6314c43f5b0d39c043a@337c53a06-5193-23f3-b681-7c8b76ce7qaa-bluemix.cloudantnosqldb.appdomain.cloud
--hmac-access-key (string)
: Cloud Object Storage access key. Required.

--hmac-secret-key (string)
: Cloud Object Storage secret key. Required.





 Examples 

ibmcloud analytics-engine-v3 instance home-set --hmac-access-key=8210ae --hmac-secret-key=03e4fc3 --output json

ibmcloud analytics-engine-v3 instance home-set --id=e64c907a-e82f-46fd-addc-ccfafbd28b09 --instance-home-id=701549e6-ab7e-43f2-8b7e-742698c53db8 --hmac-access-key=8210ae --hmac-secret-key=03e4fc3 --output json





 Example output 

The output is as follows:

{
"instance_id" : "701549e6-ab7e-43f2-8b7e-742698c53db8",
"region" : "us-south",
"endpoint" : "https://s3.direct.us-south.cloud-object-storage.appdomain.cloud",
"hmac_access_key" : "b94b",
"hmac_secret_key" : "fa8a"
}







 ibmcloud analytics-engine-v3 instance default-configs 

Get the default Spark configuration properties that will be applied to all applications of the instance.

ibmcloud analytics-engine-v3 instance default-configs [--id ID]



 Command options 

-i, --id (string)
: The ID of the Analytics Engine instance. When specified, it overrides the target instance ID if it was set. Required, if the target instance was not set.
my-slack-webhook The name of the standard key that is managed in the Key Protect service instance. 







 Using secrets references by CRN 

The following example assumes that an instance of Secrets Manager exists. It shows resources for an arbitrary secret (Slack webhook), a toolchain, an IAM service-to-service authorization policy, a Secrets Manager tool integration, and a Slack tool integration that references the webhook secret by CRN.

This example includes an ibm_sm_arbitrary_secret key resource with a payload that is set to the Slack webhook secret. It shows how to use the CRN from the key resource as the value of the secrets reference within the Slack tool integration resource. In practice, it is more secure to create the standard key ahead of time from a separate Terraform project or other process to which only limited, authorized personnel have access.

variable "slack_webhook" {}
variable "slack_channel" {}
variable "slack_team" {}
variable "secrets_manager_name" {}

data "ibm_resource_group" "rg" {
name = "default"
}

data ibm_resource_instance "sm" {
name = var.secrets_manager_name
}

resource "ibm_sm_arbitrary_secret" "key" {
instance_id = data.ibm_resource_instance.sm.guid
region = data.ibm_resource_instance.sm.location
secret_group_id = "default"
name = "my-slack-webhook"
payload = "var.slack_webhook"
}

resource "ibm_cd_toolchain" "toolchain" {
name = "tf-toolchain-secret-refs"
resource_group_id = data.ibm_resource_group.rg.id
}

resource "ibm_iam_authorization_policy" "s2s" {
source_service_name = "toolchain"
source_resource_instance_id = ibm_cd_toolchain.toolchain.id
target_service_name = "secrets-manager"
IAM_TOKEN=curl -k -X POST --header "Content-Type: application/x-www-form-urlencoded" --header "Accept: application/json" --data-urlencode "grant_type=urn:ibm:params:oauth:grant-type:apikey" --data-urlencode "apikey=$apikey" "https://iam.cloud.ibm.com/identity/token" |jq -r '(.token_type + " " + .access_token)'

To view the IAM token, run echo $IAM_TOKEN. The result should look like this:

Bearer <your token>

The Authorization header expects the token to begin with Bearer. If the result doesn't include Bearer, update the IAM_TOKEN variable to include it. These examples assume that Bearer is included in the IAM_TOKEN.

Because the IAM token expires, you must repeat the preceding step to refresh your token every hour.





 Step 3: Store the API endpoint as a variable 

Run the following command to store the API endpoint in a variable so that it can be reused later in your session.

Public endpoint:

transit_api_endpoint="https://transit.cloud.ibm.com"

Virtual private endpoint:

transit_api_endpoint="https://private.transit.cloud.ibm.com"

To verify that the variable was saved, run echo $transit_api_endpoint and ensure that the response is not empty.





 Step 4: Store the API version as a variable 

Every API request must include the version parameter, in the format YYYY-MM-DD. Run the following command to store the version date in a variable so that it can be reused in your session. For more information about setting the version parameter, see Versioning in the [Transit Gateway API](https://cloud.ibm.com/apidocs/transit-gatewayversioning)

api_version="2020-03-31"

To verify that this variable was saved, run echo $api_version and make sure that the response is not empty.
Similarly, instead of creating a service ID, generating an API key, and getting the application to store and validate that key, you can create [trusted profiles for compute resources](https://cloud.ibm.com/docs/account?topic=account-create-trusted-profile) to define fine-grained authorization for all applications that are running in a compute resource. Compute resources become identities when used as part of a trusted profile. Trust with compute resources is established by conditions based on resource attributes, or creating a direct link to a specific resource.

You can also [establish trust with IBM Cloud services](https://cloud.ibm.com/docs/account?topic=account-create-trusted-profilecreate-profile-services) that need to run an operation in your account. Or, use trusted profiels to give a [service ID](https://cloud.ibm.com/docs/account?topic=account-create-trusted-profilecreate-profile-serviceid) from another account access in your account.





 Resource identities 

The final piece of the identity concept in IAM is IBM Cloud resources, which are identified by their

cloud resource names(CRN). All resources that are created from the catalog are identified by their CRN. These CRNs are used for service-to-service authorizations in IAM. Additionally, you use a CRN to assign access to specific resources when you use the API. For more information, see [Cloud Resource Names](https://cloud.ibm.com/docs/account?topic=account-crn) and [Using authorizations to grant access between services](https://cloud.ibm.com/docs/account?topic=account-serviceauth).

For more information, see [Cloud Resource Names](https://cloud.ibm.com/docs/account?topic=account-crn) and [Using authorizations to grant access between services](https://cloud.ibm.com/docs/account?topic=account-serviceauth).
* License and entitlement
* Partner Center
* Partner Center - Sell
* Projects
* Security and Compliance Center
* Software instance
* Support center





Table 2. Roles and example actions for a policy on all account management services

 Roles Actions role_ID value 

 Viewer All viewer role actions for the account management services crn:v1:bluemix:public:iam::::role:Viewer 
 Operator All operator role actions for the account management services crn:v1:bluemix:public:iam::::role:Operator 
 Editor All editor role actions for the account management services and the ability to create resource groups crn:v1:bluemix:public:iam::::role:Editor 
 Administrator All administrator role actions for the account management services and the ability to create resource groups crn:v1:bluemix:public:iam::::role:Administrator 







 All IAM Account Management services 

Identity and Access Management (IAM) services make up a subset of all account management services. Give users access to all IAM account management services so that they can work with the following services:



* IAM Access Groups
* IAM Identity service
* IAM Access Management



* Role Management



* User Management





Table 3. Roles and example actions for a policy on all IAM account management services

 Roles Actions role_ID value 

 Viewer All viewer role actions for IAM services crn:v1:bluemix:public:iam::::role:Viewer 
 Operator All operator role actions for IAM services crn:v1:bluemix:public:iam::::role:Operator 
 Editor All editor role actions for IAM services and the ability to create resource groups crn:v1:bluemix:public:iam::::role:Editor 
 Administrator All administrator role actions for IAM services and the ability to create resource groups crn:v1:bluemix:public:iam::::role:Administrator
Any users that have a role binding to the admin cluster role now have the additional permissions from the view-pod-metrics cluster role.

oc apply -f <cluster_role_file.yaml>
3. Follow up with users that have the admin cluster role. Ask them to [refresh their cluster configuration](https://cloud.ibm.com/docs/containers?topic=containers-access_cluster) and test the action, such as oc top pods.









 Checking user permissions 

Before you complete a task, you might want to check that you have the appropriate permissions in IBM Cloud® Identity and Access Management (IAM).



 Checking IAM platform and service access roles 

Check your access policies that are assigned by IAM platform and service access roles.



 Checking IAM platform and service access roles from the UI 



1. Log in to the [IBM Cloud IAM console](https://cloud.ibm.com/iam).
2. From the navigation menu, click the Users tab.
3. In the table, click the user with the tag self for yourself or the user that you want to check.
4. Click the Access policies tab.
5. Review the Resource attributes column for a short description of the access. Click the number tag to view all the allowed actions for the role.

Service access roles are synchronized with Kubernetes RBAC roles within your cluster. If you have a service access role, you might want to [verify your RBAC role](https://cloud.ibm.com/docs/openshift?topic=openshift-userschecking-rbac), too.
6. To review what the roles and allowed actions permit, see the following topics.



* [IAM roles and actions](https://cloud.ibm.com/docs/account?topic=account-iam-service-roles-actions)
* [Red Hat OpenShift on IBM Cloud user access permissions](https://cloud.ibm.com/docs/openshift?topic=openshift-access_reference)