vania-janet/multiturn-rag-retrieval-data huggingface dataset:
* Deleting a resource instance









 IBM Cloud Identity and Access Management (IAM) 

Identity Access Management (IAM) enables you to securely authenticate users and control access to all cloud resources consistently across IBM Cloud. The IBM Cloud provisioning layer adopted IAM for authentication and authorization of actions that are taken against the provisioning layer. Third-party product providers use IAM to create an authentication flow (OAuth). See [What is IAM?](https://cloud.ibm.com/docs/account?topic=account-iamoverview) for more information.

If your product uses OpenID Connect (OIDC) libraries, IAM supports OIDC integration. OIDC is an authentication layer on top of OAuth 2.0, an authorization framework and can help simplify the onboarding process. For more information on OIDC, see [Open ID Connect](http://openid.net/connect/).





 IBM Cloud catalog 

The IBM Cloud catalog stores and displays the product definitions (descriptions, features, images, URLs, keywords, and other product definitions) of the product that you onboard. IBM Cloud Partner Center provides a way to define all aspects of your service's required metadata. You can find detailed information about the required and optional metadata fields on the Dashboard, Product details, and Pricing tabs in Partner Center. This metadata is published and displayed in the catalog. Take a look at the following key items to jumpstart your understanding:

Programmatic name
: The programmatic name is your product's unique ID and is used within all IBM services and tools. This name is not the display name of your product that customers see in the IBM Cloud catalog. The programmatic name is automatically generated from your company name and the display name of your product.

Display name
: A name for your service. This name is publicly displayed in the IBM Cloud catalog. For example, Compose Redis

Service ID
: A service ID is used to identify your service when it communicates with other IBM Cloud services. You're also required to create an API key for your service ID.

Company or product logo
: An SVG file with your product logo.
* UI
* CLI
* API







 Protecting Secrets Manager resources with context-based restrictions 

After you set up your IBM Cloud® Secrets Manager service instance, you can manage access by using [context-based restrictions (CBR)](https://cloud.ibm.com/context-based-restrictions/overview).



 Managing CBR settings 

With [context-based restrictions](https://cloud.ibm.com/docs/account?topic=account-context-restrictions-whatis), you can define and enforce user and service access restrictions to Secrets Manager resources based on specified criteria.

You can control Secrets Manager resources with context-based restrictions and identity and access management (IAM) policies. These resources include Virtual Private Cloud (VPC) references and Internet Protocol (IP) addresses that are linked to your Secrets Manager instance.

These restrictions work with traditional IAM policies, which are based on identity, to provide an extra layer of protection. Unlike IAM policies, context-based restrictions don't assign access. Context-based restrictions check that an access request comes from an allowed context that you configure. Since both IAM access and context-based restrictions enforce access, context-based restrictions offer protection even in the face of compromised or mismanaged credentials. For more information, see [What are context-based restrictions](https://cloud.ibm.com/docs/account?topic=account-context-restrictions-whatis).

A user must have the Administrator role on the Secrets Manager service to create, update, or delete rules. A user must also have either the Editor or Administrator role on the context-based restrictions service to create, update, or delete network zones. A user with the Viewer role on the context-based restrictions service can add only network zones to a rule.

Any IBM Cloud Activity Tracker or audit log events that are generated come from the context-based restrictions service, not Secrets Manager. For more information, see [Monitoring context-based restrictions](https://cloud.ibm.com/docs/account?topic=account-cbr-monitor).
* iamrefresh The password contains an IAM refresh token that is used internally by the registry to generate an IAM access token. This type of authentication is longer lived. This authentication type is used by the ibmcloud cr login command.
* iamapikey The password is an IAM API key that is used internally by the registry to generate an IAM access token. This type of authentication is the preferred type for automation. You can use a user API key or a service ID API key. For more information, see [Accessing your namespaces in automation](https://cloud.ibm.com/docs/Registry?topic=Registry-registry_accessregistry_access_automating).
ibmcloud oc ingress domain credential get --cluster mycluster







 ibmcloud oc ingress domain credential rm 

Remove external domain provider credentials from the cluster.

ibmcloud oc ingress domain credential rm --cluster CLUSTER [-q]

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

Command options:

-c, --cluster CLUSTER
: Required: The name or ID of the cluster where the credential is applied.

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



 Example ingress domain credential rm command 

ibmcloud oc ingress domain credential rm --cluster mycluster







 ibmcloud oc ingress domain credential set akamai 

Add external Akamai domain credentials to your cluster.

ibmcloud oc ingress domain credential set akamai --cluster CLUSTER [--access-token TOKEN] [--client-secret SECRET] [--client-token TOKEN] [--host HOST] [-q] [--domain-zone ZONE]

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 where you want to add the credentials.

--access-token TOKEN
: The access token for the Akamai API Client credentials. This token is provided by Akamai.

--client-secret SECRET
: The client secret for the Akamai API Client credentials. This secret is provided by Akamai.

--client-token TOKEN
: The client token for the Akamai API Client credentials. This token is provided by Akamai.

--host HOST
: The host for the Akamai API Client credentials.

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

--domain-zone ZONE
: The DNS zone that exists in your external account and is specified in the Akamai credentials.
ibmcloud secrets-manager secret-version-metadata-update --secret-type=arbitrary --id=exampleString --version-id=exampleString --metadata='{"collection_type": "application/vnd.ibm.secrets-manager.secret+json", "collection_total": 1}' --resources='[{"version_custom_metadata": {"anyKey": "anyValue"}}]'







 ibmcloud secrets-manager secret-metadata 

Get the details of a secret by specifying its ID.

A successful request returns only metadata about the secret, such as its name and creation date. To retrieve the value of a secret, use the Get a secret or Get a version of a secret methods.

ibmcloud secrets-manager secret-metadata --secret-type SECRET-TYPE --id ID



 Command options 

--secret-type (string)
: The secret type. Required.

Allowable values are: arbitrary, iam_credentials, imported_cert, public_cert, private_cert, username_password, kv.

--id (string)
: The v4 UUID that uniquely identifies the secret. Required.

The value must match regular expression /[0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12}/.





 Examples 

ibmcloud secrets-manager secret-metadata --secret-type=arbitrary --id=exampleString







 ibmcloud secrets-manager secret-metadata-update 

Update the metadata of a secret, such as its name or description.

To update the actual contents of a secret, rotate the secret by using the Invoke an action on a secret method.

ibmcloud secrets-manager secret-metadata-update --secret-type SECRET-TYPE --id ID --metadata METADATA --resources RESOURCES



 Command options 

--secret-type (string)
: The secret type. Required.
CLUSTER_CRN=$(ibmcloud ks cluster get --cluster my-test-cluster --output json | jq -r '.crn')
SECRETS_MANAGER_CRN=$(ibmcloud resource service-instance my-secrets-manager --output JSON | jq -r '.[0].crn')
2. Create the profile.

ibmcloud iam trusted-profile-create 'External Secrets'
3. Authorize the Kubernetes cluster to use the trusted profile.

ibmcloud iam trusted-profile-rule-create 'External Secrets' --name kubernetes --type Profile-CR --conditions claim:namespace,operator:EQUALS,value:external-secrets --conditions claim:name,operator:EQUALS,value:external-secrets --conditions claim:crn,operator:EQUALS,value:$CLUSTER_CRN --cr-type IKS_SA
4. Create an access policy that allows the trusted profile to read secrets from your Secrets Manager instance.

ibmcloud iam trusted-profile-policy-create 'External Secrets' --roles SecretsReader --service-instance $SECRETS_MANAGER_CRN --service-name secrets-manager







 Prepare your Secrets Manager instance 

Finally, configure your Secrets Manager instance to start working with secrets.



1. From the command line, verify that you can access the Secrets Manager CLI plug-in.

ibmcloud secrets-manager --help

Don't have the plug-in yet? To install the Secrets Manager CLI plug-in, run ibmcloud plugin install secrets-manager.
2. Export an environment variable with your unique Secrets Manager API endpoint URL.

export SECRETS_MANAGER_URL=ibmcloud resource service-instance my-secrets-manager --output json | jq -r '.[].dashboard_url | .[0:-3]'; echo $SECRETS_MANAGER_URL
3. Create a secret group for your instance.
For IAM-enabled services, the credentials are automatically created with the Writer service access role, but you can use the --role option to specify a different service access role. If you use the --key option, don't include the --role option.

If your service supports private cloud service endpoints, you can manually create the service credentials with the private cloud service endpoint, and then use the --key option to specify the name of your credentials.

ibmcloud oc cluster service bind --cluster <cluster_name_or_ID> --namespace <project> --service <service_instance_name> [--key <service_instance_key>] [--role <IAM_service_role>]

When the creation of the service credentials is successful, a Kubernetes secret with the name binding-<service_instance_name> is created.

Example output

ibmcloud oc cluster service bind --cluster mycluster --namespace myproject --service cleardb
Binding service instance to namespace...
OK
Namespace: myproject
Secret name: binding-<service_instance_name>
5. Verify the service credentials in your Kubernetes secret.



1. Get the details of the secret and note the binding value. The binding value is base64 encoded and holds the credentials for your service instance in JSON format.

oc get secrets binding-<service_instance_name> --namespace=<project> -o yaml

Example output

apiVersion: v1
data:
binding: <binding>
kind: Secret
metadata:
annotations:
service-instance-id: 1111aaaa-a1aa-1aa1-1a11-111aa111aa11
service-key-id: 2b22bb2b-222b-2bb2-2b22-b22222bb2222
creationTimestamp: 2018-08-07T20:47:14Z
name: binding-<service_instance_name>
namespace: <project>
resourceVersion: "6145900"
To generate an IAM access token that represents the trusted profile, provide the CR-token for IAM. One CR-token might resolve to multiple trusted profiles, therefore you must pass either profile_id or profile_name as a parameter. If both parameters are specified, they must resolve to the same compute resource, otherwise the API call fails.

$ curl -X POST -H "Content-Type: application/x-www-form-urlencoded"
-H "Accept: application/json"
-d grant_type=urn:ibm:params:oauth:grant-type:cr-token
-d cr_token=$(CRTOKEN)
-d profile_name=TestProfile
https://iam.cloud.ibm.com/identity/token

The compute resource and the trusted profile must be in the same account. Trusted profiles from another account that would have matching rules are not considered.
IAM condition properties 

Dynamic rules and trusted profiles both use conditional IAM statements that you specify to automatically add federated users to access groups or trusted profiles. When users log in with a federated ID, the data from the identity provider (IdP) dynamically maps them to an access group based on conditions that you set. For more information, see [Creating dynamic rules for access groups](https://cloud.ibm.com/docs/account?topic=account-rules) and [Creating trusted profiles](https://cloud.ibm.com/docs/account?topic=account-create-trusted-profile).

You can also assign conditional IAM access policies to designate temporary access to resources in your account or allow access to resources during specific time windows. For more information, see [Limiting access with time-based conditions](https://cloud.ibm.com/docs/account?topic=account-iam-time-based) and review the section [Conditions in /v2/policies access policies](https://cloud.ibm.com/docs/account?topic=account-iam-condition-properties&interface=uipolicy-condition-properties).



 Rule and profile details 

Each dynamic rule and trusted profile trust relationship has the following properties:

Name
: Enter a custom name that helps you remember what type of users you are adding to an access group or trusted profile.

Identity provider (IdP)
: The dynamic rule or trusted profile is evaluated only if the user who is logging in authenticates by using the enterprise IdP with this issuer URI. Your IdP URL is displayed in the console for you to copy and paste when you create a dynamic rule or trusted profile. For example, https://w3id.sso.ibm.com/auth/sps/samlidp2/saml20. You can also view th IdP by clicking View identity provider (IdP) data. For IBMid, the IdP is the SAML "entityId" field, sometimes referred to as the issuer ID, and is part of the federation configuration when you are onboarding with IBMid. For AppID, equivalent syntax is the "realm ID".
ibmcloud ks ingress domain credential rm 

Remove external domain provider credentials from the cluster.

ibmcloud ks ingress domain credential rm --cluster CLUSTER [-q]

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

Command options:

-c, --cluster CLUSTER
: Required: The name or ID of the cluster where the credential is applied.

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



 Example ingress domain credential rm command 

ibmcloud ks ingress domain credential rm --cluster mycluster







 ibmcloud ks ingress domain credential set akamai 

Add external Akamai domain credentials to your cluster.

ibmcloud ks ingress domain credential set akamai --cluster CLUSTER [--access-token TOKEN] [--client-secret SECRET] [--client-token TOKEN] [--host HOST] [-q] [--domain-zone ZONE]

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 where you want to add the credentials.

--access-token TOKEN
: The access token for the Akamai API Client credentials. This token is provided by Akamai.

--client-secret SECRET
: The client secret for the Akamai API Client credentials. This secret is provided by Akamai.

--client-token TOKEN
: The client token for the Akamai API Client credentials. This token is provided by Akamai.

--host HOST
: The host for the Akamai API Client credentials.

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

--domain-zone ZONE
: The DNS zone that exists in your external account and is specified in the Akamai credentials. Specify the full zone name, such as example.external.adppdomain.cloud.
The service credential JSON looks like the following example:

{
"apikey": "MxVp86XHkU82Wc97tdvDF8qM8B0Xdit2RqR1mGfVXPWz",
"host": "2922d728-27c0-4c7f-aa80-1e59fbeb04d0-bluemix.cloudant.com",
"iam_apikey_description": "Auto generated apikey during resource-key [...]",
"iam_apikey_name": "auto-generated-apikey-050d21b5-5f[...]",
"iam_role_crn": "crn:v1:bluemix:public:iam::::serviceRole:Manager",
"iam_serviceid_crn": "crn:v1:staging:public:iam-identity::[...]",
"url": "https://76838001-b883-444d-90d0-46f89e942a15-bluemix.cloudant.com",
"username": "76838001-b883-444d-90d0-46f89e942a15-bluemix"
}

The values for the previous example are described in the following list:

apikey
: IAM API key.

host
: The DNS that resolves domain names with their corresponding IP addresses.

iam_apikey_description
: Description of IAM API key.

iam_apikey_name
: ID of IAM API key.

iam_role_crn
: The IAM role that the IAM API key has.

iam_serviceid_crn
: The CRN of service ID.

url
: IBM Cloudant service URL.

username
: The internal IBM Cloudant account name.
"iam_role_crn": "crn:v1:bluemix:public:iam::::serviceRole:Manager",
"iam_serviceid_crn": "crn:v1:staging:public:iam-identity::[...]",
"url": "https://76838001-b883-444d-90d0-46f89e942a15-bluemix.cloudant.com",
"username": "76838001-b883-444d-90d0-46f89e942a15-bluemix"
}

The values for the previous example are described in the following list:

apikey
: IAM API key.

host
: The DNS that resolves domain names with their corresponding IP addresses.

iam_apikey_description
: Description of IAM API key.

iam_apikey_name
: ID of IAM API key.

iam_role_crn
: The IAM role that the IAM API key has.

iam_serviceid_crn
: The CRN of service ID.

url
: IBM Cloudant service URL.

username
: The internal IBM Cloudant account name.

For more information, see [IBM Cloud API keys and Use only IAM](https://cloud.ibm.com/docs/Cloudant?topic=Cloudant-managing-access-for-cloudantibm-cloudant-api-keys-and-use-only-iam_ai).





 How do I rotate my credentials? 

In most cases, rotating credentials is a straight-forward process:



1. Generate a replacement service credential. For more information, see [How can I generate service credentials?](https://cloud.ibm.com/docs/Cloudant?topic=Cloudant-faq-authenticating-cloudantfind-service-credentials-iam).
2.
Configure an IAM credential with a lease duration of 1 hour and assign it to the default secret group.

vault write -format=json ibmcloud/iam_credentials/roles/test-iam-credentials access_groups=AccessGroupId-985dc0a3-857b-48bd-b6d6-33819da7ba42 ttl=1h description="My test IAM credential." labels=test,us-south

Configure an IAM credential with a lease duration of 1 hour and assign it to a specified secret group.

vault write -format=json ibmcloud/iam_credentials/roles/groups/9ab2250f-a369-4e07-ade7-d417d63ad587/test-iam-credential-in-group access_groups=AccessGroupId-985dc0a3-857b-48bd-b6d6-33819da7ba42 ttl=1h description="My test IAM credential that is assigned to a secret group." labels=test,us-south





 Output 

The command returns the following output:

{
"request_id": "d4150a28-1184-8864-dcd3-15b0d18da7c1",
"lease_id": "",
"lease_duration": 0,
"renewable": false,
"data": {
"access_groups": [
"AccessGroupId-985dc0a3-857b-48bd-b6d6-33819da7ba42"
],
"created_by": "iam-ServiceId-b7ebcf90-c7a9-495b-8ce8-bbf33cb95ca0",
"creation_date": "2020-10-09T17:13:47Z",
"version_id" : "7bf3814d-58f8-4df8-9cbd-f6860e4ca973",
"version_alias" : "current",
"locks" : "lock-3", "lock-4" ],
"payload_available" : true
}, {
"version_id" : "5bf89b0c-df55-c8d5-7ad6-8816951c6784",
"version_alias" : "previous",
"locks" : "lock-example-1", "lock-example-2" ],
"payload_available" : true
} ]
}









 Configurations 

Create and manage configurations so that you can work with specific types of secrets.



 ibmcloud secrets-manager configuration-create 

Add a configuration to the specified secret type.

Use this operation to define the configurations that are required to create public certificates (public_cert), private certificates (private_cert) and IAM Credentials secrets (iam_credentials).

You can add multiple configurations for your instance as follows:



* A single configuration for IAM Credentials.
* Up to 10 CA configurations for public certificates.
* Up to 10 DNS configurations for public certificates.
* Up to 10 Root CA configurations for private certificates.
* Up to 10 Intermediate CA configurations for private certificates.
* Up to 10 Certificate Template configurations for private certificates.



ibmcloud secrets-manager configuration-create --configuration-prototype CONFIGURATION-PROTOTYPE



 Command options 

--configuration-prototype ([ConfigurationPrototype](https://cloud.ibm.com/docs/cli?topic=cli-secrets-manager-clicli-configuration-prototype-example-schema))
: The details of your configuration. Required.

Provide a JSON string option or specify a JSON file to read from by providing a filepath option that begins with a @, e.g. --configuration-prototype=@path/to/file.json.





 Example
echo PUBLIC_CERT_ID $(printenv PUBLIC_CERT_ID)

You can test the secrets manager variables with this command:

ibmcloud sm secret --service-url $SECRETS_MANAGER_API_URL --secret-type public_cert --id $PUBLIC_CERT_ID
7. Run the below command to generate a new copy of secure-file-storage.yaml. It will use all of the environment variables you configured together with the template file secure-file-storage.template.yaml. You may want to first save the current version:

cp secure-file-storage.yaml /tmp

./generate_yaml.sh
8. Apply the configuration changes to your cluster:

kubectl apply -f secure-file-storage.yaml
9. Switch back to the browser. In the [IBM Cloud Resource List](https://cloud.ibm.com/resources) locate the previously created and configured App ID service and launch its management dashboard.



* Click Manage Authentication on the left and the Authentication Settings tab on the top.
* In the Add web redirect URLs form add https://secure-file-storage.example.com/oauth2-secure-file-storage-appid/callback as another URL.



10. Everything should be in place now. Test the app by accessing it at your configured custom domain https://secure-file-storage.<your custom domain>.









 Step 6: Security: Rotate service credentials 

To maintain security, service credentials, passwords and other keys should be replaced (rotated) a regular basis. Many security policies have a requirement to change passwords and credentials every 90 days or with similar frequency. Moreover, in the case an employee leaves the team or in (suspected) security incidents, access privileges should be changed immediately.

In this tutorial, services are utilized for different purposes, from storing files and metadata over securing application access to managing container images. Rotating the service credentials typically involves



* renaming the existing service keys,
* creating a new set of credentials with the previously used name,