vania-janet/multiturn-rag-retrieval-data huggingface dataset:
Known issues and limits 

IBM Cloud® Secrets Manager includes the following known issues and limits that might impact your experience.



 Known issues 

Review the following known issues that you might encounter as you use Secrets Manager.



Table 1. Known issues and limitations that apply to the Secrets Manager service

 Issue Workaround 

 Multiple secrets of the same type can't be created with the same name. It is not possible to create more than one secret of the same type with the same name. This limitation applies at the instance level. To organize similar secrets of the same type across multiple secret groups in your instance, try adding a prefix or suffix to the names of those secrets. 
 Secrets can't be transferred between secret groups. If you accidentally assign a secret to the wrong secret group, or if you don't want a secret to belong to the default secret group, you must delete the secret and create a new one. 
 API keys that are associated with an IAM secret aren't valid immediately after they are generated. If you have automation in place that calls the Secrets Manager API to get the API key for an IAM secret, add a wait delay of 2 seconds to allow the new API key to be recognized by IAM. 
 IAM credentials with a time-to-live (TTL) don't immediately expire. After a secret with a TTL reaches the end of its lease duration, expect a tolerance of 1 - 2 minutes before the secret's associated service ID is deleted by IAM. 
 Certificates that you order from Let's Encrypt can't have a Common Name (CN) that exceeds 64 characters in length. As a workaround, during the certificate order process, you can configure a shorter domain name so that it can be used as the certificate CN in your DNS provider. Then, you can order a multi-domain SAN certificate that uses the same shortened domain as the CN, along with longer application domains that are specified as Subject Alternative Names (SANs). 
 Users that have Writer or Manager service access that is scoped to secret groups are unable to create some types of secrets when they use the Secrets Manager UI.
Capabilities include Java, mobile back-end development, and application monitoring, as well as features from ecosystem partners and open source—all provided as-a-service in the cloud.





 identity and access management (IAM) 

The process of controlling access of authorized users to data and applications, while helping companies comply with various regulatory requirements.





 identity provider (IdP) 

A service that creates, maintains, and manages identity information, account authentication and credential management services for one or more systems. For example, a user registry for one or more hosts; or a built-in user registry for an application.





 IdP 

See [identity provider](https://cloud.ibm.com/docs/overview?topic=overview-glossaryx2714740).





 image 

A file system and its execution parameters that are used within a container runtime to create a container. The file system consists of a series of layers, combined at runtime, that are created as the image is built by successive updates. The image does not retain state as the container executes. See also [container](https://cloud.ibm.com/docs/overview?topic=overview-glossaryx2010901), [registry](https://cloud.ibm.com/docs/overview?topic=overview-glossaryx2064940), [namespace](https://cloud.ibm.com/docs/overview?topic=overview-glossaryx2031005), [layer](https://cloud.ibm.com/docs/overview?topic=overview-glossaryx2028320), [base image](https://cloud.ibm.com/docs/overview?topic=overview-glossaryx5366487), [parent image](https://cloud.ibm.com/docs/overview?topic=overview-glossaryx8439210), [private image repository](https://cloud.ibm.com/docs/overview?topic=overview-glossaryx8439215).





 imprint mode 

An operational mode in which crypto units are assigned to a user.





 infrastructure as a service (IaaS)
* UI
* CLI
* API
* Terraform







 Creating intermediate certificate authorities 

An intermediate certificate authority (CA) is a lower-level certificate authority that can sign and issue certificates to an end-entity, such as an app or website. In IBM Cloud® Secrets Manager, you can use an intermediate CA to create [private certificates](https://cloud.ibm.com/docs/secrets-manager?topic=secrets-manager-certificatescreate-certificates).

If you already created a parent CA in your Secrets Manager instance, for example a root CA or an intermediate CA, you can use it to sign and issue an intermediate CA. If you created the parent CA elsewhere outside of Secrets Manager, you can also use that CA to sign an intermediate CA.

You can create up to 10 intermediate certificate authorities per instance. To view a list of the configurations that are available for your instance, go to the Secrets engines > Private certificates page in the Secrets Manager UI.



 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).



 Supported signing methods 

The service offers two options:



Table 1. Options for creating an intermediate CA

 Signing options When to use 

 Internally signed You're building a chain of certificates that uses an existing parent CA, for example a root CA or another intermediate CA, as its trust anchor. The parent CA was previously created in the same Secrets Manager instance. 
 Externally signed If you created a parent CA offline or in another Secrets Manager service instance, you can use the external CA to sign and issue an intermediate certificate authority. 









 Creating an intermediate CA with internal signing in the UI 

An intermediate CA with internal signing uses a parent CA that was previously created in your Secrets Manager instance as its trust anchor. You can create an intermediate CA with internal signing by using the Secrets Manager UI.



1. In the console, click the Menu icon !
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 Security and Compliance Center Workload Protection service in the account.

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

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
Getting the Object Storage credentials 

To work with Object Storage in IBM Analytics Engine, you need the Object Storage credentials which can be the:



* API key: The IAM API key and the Object Storage service endpoint
* HMAC keys: The access key, secret key and the Object Storage service endpoint





 Access management in Object Storage 

To securely authenticate to Object Storage, you need to understand the concepts of Identity and Access Management (IAM), and how and when to use service credentials and API Keys in the context of Object Storage. As the service administrator, IAM offers you flexibility and fine-grained access control to a service instance and it's resources both for direct platform access and service API calls. See [IAM overview](https://cloud.ibm.com/docs/cloud-object-storage/iam?topic=cloud-object-storage-iam-overview).

The following diagram illustrates access management to Object Storage.

Zoom

![Access management in Object Storage](https://cloud.ibm.com/docs-content/v1/content/cd4be197c8921ed12923aa899ac93a8ab643c158/AnalyticsEngine/images/iam-overview.svg)

Figure 1. Access management to IBM Cloud Object Storage

As the Object Storage administrator, you can:



* [Create service IDs](https://cloud.ibm.com/docs/AnalyticsEngine?topic=AnalyticsEngine-get-cos-credentials-serverlesscreating-service-ids)
* [Invite users and grant permissions](https://cloud.ibm.com/docs/AnalyticsEngine?topic=AnalyticsEngine-get-cos-credentials-serverlessinviting-users-and-granting-permissions)







 Creating service IDs 

When you create service IDs to access an Object Storage service instance, the IDs are Object Storage service IDs and not IDs tied to a user.

As system administrator, you can:



* Create service IDs with access rights at instance level
To configure a secrets engine from the IBM Cloud CLI, run the [ibmcloud secrets-manager config-update](https://cloud.ibm.com/docs/secrets-manager?topic=secrets-manager-cli-plugin-secrets-manager-clisecrets-manager-cli-configuration-update-command) command.

ibmcloud secrets-manager config-update 
--engine-config='{"api_key": "API_KEY"}'

Using a Windows™ command prompt (cmd.exe) or PowerShell? If you encounter errors with passing JSON content on the command line, you might need to adjust the strings for quotation-escaping requirements that are specific to your operating system. For more information, see [Using quotation marks with strings in the IBM Cloud CLI](https://cloud.ibm.com/docs/cli?topic=cli-quote-strings).







 Configuring the IAM credentials engine with the API 

Before you can create dynamic IAM credentials, you must configure the IAM secrets engine for your service instance. You can configure a secrets engine programmatically by calling the Secrets Manager API.

First, you need an [IBM Cloud API key](https://cloud.ibm.com/docs/account?topic=account-serviceidapikeys) that is associated with a service ID in your IBM Cloud account. To allow your IBM Cloud API key to create and manage other API keys dynamically, its associated service ID must have Editor platform access for the IAM Access Groups Service, and Operator platform access for the IAM Identity Service.

For step-by-step instructions to create an IBM Cloud API key with the correct level of access, switch to the UI or CLI steps.

The following example shows a query that you can use to configure a secrets engine for your instance. When you call the API, replace the API key variables and IAM token with the values that are specific to your Secrets Manager instance.

curl -X POST
* UI
* CLI
* API
* Terraform







 Creating root certificate authorities 

With IBM Cloud® Secrets Manager, you can build and manage your own public key infrastructure (PKI) system by creating root and intermediate certificate authorities (CA).

A certificate authority (CA) is the entity that signs and issues your SSL/TLS certificates. If you're looking for the ability to quickly generate a self-signed certificate, you can use Secrets Manager to create an internally signed root CA. You can use this CA as the trust anchor for a certificates chain. After you create a root CA for your instance, you can use it to sign a lower-level or subordinate CA, for example other intermediate CAs that you create in the service.

You can create up to 10 root certificate authorities per instance. To view a list of the configurations that are available for your instance, go to the Secrets engines > Private certificates page in the Secrets Manager UI.



 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).





 Creating a root certificate authority in the UI 

You can create an internally signed root certificate authority for your service instance by using the Secrets Manager UI.



1. In the console, click the Menu icon ![Menu icon](https://cloud.ibm.com/docs-content/v1/content/991f60ddbe3ab0a9aa69481a07a0a73b359fa329/icons/icon_hamburger.svg)> Resource List.
2. From the list of services, select your instance of Secrets Manager.
3. In the Secrets engines page, click the Private certificates tab.
4. In the Certificate authorities table, click Create certificate authority to start the creation wizard.
5. Specify the certificate authority type and options.



1. Select Root certificate authority as the authority type.
2. Enter a name to easily identify your certificate authority.
3.
RBAC, groups and IAM integration 

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. Groups provide an isolated workspace in an IBM Log Analysis instance for a user or group of users to have access to auditing events in a defined scope.

IAM can map a combination of groups and roles so that a user only has access to a specific set of auditing events and can take a defined set of actions within the product.

Groups provide additional security by only allowing users to see a subset of auditing events, as opposed to all auditing events that are generated in the account. For example, you could grant a group of users access to only see auditing events that are related to development services in the account.

In an Log Analysis instance, you can define 1 or more groups.



* A group provides an isolated workspace for a user or group of users to have access to auditing events with a defined scope.
* An administrator of the service can configure multiple groups.



By default, when you grant a user access to work with the Log Analysis service, the user can see all auditing events.



* A user can be a member of 1 or more groups.
* Users in a group have access to the data that is in scope of the group.



For a user to monitor data within the context of a group, you must grant the user a policy for the IBM Log Analysis service. The policy specifies the group and the service permissions for the user so the user can work with the data in scope for that group.

You can grant any of the following IAM service roles:



* Standard-member: A standard-member role allows a user to monitor data through views, dashboards, screens, and alerts, and to manage resources such as dashboards, and alerts that are in scope for the group.
* Reader: A reader role allows a user to monitor data through views, dashboards, screens, and alerts that are in scope for the group.
* Manager: The manager role is an instance level role that grants administrative permissions. If you grant this role in a policy for a group, you are granting admin permissions over the instance to the users that belong to that group.
-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. If the payload_available field has a value of true, it means that you're able to access or [restore the secret data of that version](https://cloud.ibm.com/docs/secrets-manager?topic=secrets-manager-version-historyrestore-secret-api).
"host": "76838001-b883-444d-90d0-46f89e942a15-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::[...]",
"password": "8fb6a16b48903e87b769e7f4968521e85c2394ed8f0e69b2769e56dcb27d2e76",
"port": 443,
"url": "https://<username>:<password>@76838001-b883-444d-90d0-46f89e942a15-bluemix.cloudant.com",
"username": "apikey-v2-58B528DF5397465BB6673E1B79482A8C"
}

Each value in the previous JSON example must be interpreted by using the following definitions:

apikey
: IAM API key.

host
: IBM Cloudant service hostname.

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.

password
: The IBM Cloudant legacy credential password.

port
When you call the API, replace the ID variables and IAM token with the values that are specific to your Secrets Manager instance.

You can find the event_notifications_instance_crn value in the console by going to the Resource list and clicking the Event Notifications instance row.

curl -X POST
--H "Authorization: Bearer {iam_token}" --H "Accept: application/json" --H "Content-Type: application/json" --d'{
"event_notifications_instance_crn": "crn:v1:bluemix:public:event-notifications:us-south:a/22018f3c34ff4ff193698d15ca316946:578ad1a4-2fd8-4e66-95d5-79a842ba91f8::",
"event_notifications_source_description": "Optional description of this source in an Event Notifications instance.",
"event_notifications_source_name": "My Secrets Manager"
}' "https://{instance_ID}.{region}.secrets-manager.appdomain.cloud/api/v2/notifications/registration"

A successful request returns the CRN value of your connected Event Notifications service instance. For more information about the required and optional request parameters, see the [API docs](https://cloud.ibm.com/apidocs/secrets-manager/secrets-manager-v2).





 Connecting to Event Notifications with Terraform 

The following example shows a configuration that you can use to to register your Secrets Manager source details with Event Notifications.

resource "ibm_sm_en_registration" "en_registration" {
instance_id = local.instance_id
region = local.region
name = "test-root-ca"
event_notifications_instance_crn = var.en_instance_crn
event_notifications_source_description = "My event notification source"
event_notifications_source_name = "my_en_source"
}
Satellite Config <br><br> * Provide an interface to assign access control to configurations via IAM.<br><br><br> <br><br> * Use the provided tools to [manage authentication, authorization, and access control policies](https://cloud.ibm.com/docs/satellite?topic=satellite-iam) to use Satellite configurations and subscriptions to create, update, and delete Kubernetes resources. Note that access in IAM to Satellite Config does not give users access to the clusters, nor the ability to log in and manage the Kubernetes resources from the cluster. Users with access to a cluster might log in and manually change the Kubernetes resources.<br><br><br> 
 Satellite Link <br><br> * Provide an interface to assign access control to endpoints via IAM.<br><br><br> <br><br> * Use the provided tools to [manage authentication, authorization, and access control policies](https://cloud.ibm.com/docs/satellite?topic=satellite-iam).<br><br><br> 
 Satellite Storage N/A <br><br> * Decide and configure read and write access to storage for your apps by using persistent volumes and persistent volume claims.<br><br><br> 
 Satellite-enabled services <br><br> * Review each service's documentation for additional responsibilities that IBM maintains.<br><br><br> <br><br> * Review each service's documentation for additional responsibilities that you fulfill when you use these services.<br><br><br> 
 Satellite Connector Provide an interface to assign access control to connectors through IAM. Use the provided tools to manage authentication, authorization, and access control policies. 
 Satellite Connector Agent Image Provide an interface for the Satellite Connector Agent image to connect to a Satellite Connector by leveraging IBM IAM credentials. Maintain and rotate the IAM credentials needed by the agent image. 







 Security and regulation compliance 

Security and regulation compliance includes tasks such as security controls implementation and compliance certification.



Table 5. Responsibilities for security and regulation compliance.

 Task IBM responsibilities Your responsibilities
Preparing to order public certificates 

You can enable your IBM Cloud® Secrets Manager service instance to order certificates by configuring the public certificates engine.

In Secrets Manager, the public certificates engine serves as the back end for the public_cert secret type. Public certificates are domain-validated TLS certificates that you can order and manage in the service. Before you can order a certificate, you must enable your service instance by connecting supported certificate authorities (CA) and DNS providers.

[Ordering a certificate](https://cloud.ibm.com/docs/secrets-manager?topic=secrets-manager-public-certificatesorder-public-certificates) through Secrets Manager is an asynchronous process that can take a few minutes to complete.



 Supported certificate authorities 

A certificate authority (CA) is an entity that issues digital certificates. You can connect the following certificate authorities with your Secrets Manager service instance.



Table 1. Certificate authority options

 Authority Description 

 [Let's Encrypt](https://letsencrypt.org/) Let’s Encrypt is a free, automated, ACME-based certificate authority that provides domain validated certificates valid for 90 days. It is a service that is provided by the Internet Security Research Group (ISRG). 





 Creating a Let's Encrypt ACME account 

To connect with Let's Encrypt, Secrets Manager uses the [Automatic Certificate Management Environment (ACME)](https://datatracker.ietf.org/doc/html/rfc8555) protocol. The ACME protocol makes it possible to automatically obtain browser trusted certificates from a certificate authority without human intervention.

You can grant service access to Let's Encrypt by registering an ACME account and providing your account credentials. If you have a working ACME client or account for Let's Encrypt, you can use your existing private key. If you don't have an account yet, you can create one by using the [ACME account creation tool](https://github.com/ibm-cloud-security/acme-account-creation-tool).

Certificate authorities can apply a charge when you are ordering or renewing a certificate.