vania-janet/multiturn-rag-retrieval-data huggingface dataset:
lifecycle {
ignore_changes = [
password,
]
}
}



2. After 10 days, the secret is auto-rotated in Secrets Manager. When you check the Terraform plan, it shows that the password field was changed outside of Terraform, as displayed in the following example.



terraform plan
data.ibm_resource_instance.sm_resource_instance: Reading...
data.ibm_resource_instance.sm_resource_instance: Read complete after 6s [id=crn:v1:bluemix:public:secrets-manager:eu-gb:a/1efe69ceedd307f4de6f5fb6296a34b1:73d9bf0e-7b82-453d-a9bf-bfdceceb55bd::]
ibm_sm_username_password_secret.test_username_password_secret: Refreshing state... [id=1a87fb02-9025-8b41-77b5-6bf76d52ba72]

Note: Objects have changed outside of Terraform

Terraform detected the following changes made outside of Terraform since the last "terraform apply" which may have affected this plan:

 ibm_sm_username_password_secret.sm_username_password_secret has changed
 resource "ibm_sm_username_password_secret" "test_username_password_secret" {
id = "1a87fb02-9025-8b41-77b5-6bf76d52ba72"
name = "test-user-creds-secret"
 password = (sensitive value)
 (15 unchanged attributes hidden)

 (1 unchanged block hidden)
}
Unless you have made equivalent changes to your configuration, or ignored the relevant attributes using ignore_changes, the following plan may include actions to undo
Hi or respond to these changes.



3. Applying the Terraform plan syncs the user credentials password field in Terraform with the new version value.



A successful response returns the ID value for the secret, along with other metadata.
its trade secrets, irrespective of what has been deposited with the
 U.S. Copyright Office.
 =============================================================================


 Description: Reregister an RHEL virtual server instance to its respective capsule server


PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin

argumentsFound=false
FILE_DIR=/var/lib/cloud/instance/scripts/vendor
file=$(grep -src -r -w 'REDHAT_CAPSULE_SERVER|OS_INSTALL_CODE' $FILE_DIR | awk -F: '$2 == 6 {print $1}')
echo "Processing $file..."
if [ -f "$file" ]; then
capsule="$(grep "REDHAT_CAPSULE_SERVER=" $file | cut -d" -f2)"
organization="$(grep "OS_REDHAT_ORG_NAME=" $file | cut -d" -f2)"
activationKey="$(grep "ACTIVATION_KEYS=" $file | cut -d" -f2)"
profileName="$(grep "PROFILENAME=" $file | cut -d" -f2)"
if [! -z "$capsule" ] && [! -z "$organization" ] && [! -z "activationKey" ] && [! -z "profileName" ]; then
argumentsFound=true
fi
fi

if [ "$argumentsFound" = false ]; then
if [ -z "$4" ]; then
echo Please provide capsule hostname, organization, activation key and profile name
exit
fi
* The action to rotate a secret is now the create a new secret version API: POST/v2/secrets/{id}/versions.
* The action to restore secret version is now the create a new secret version API with the restored_from_version body parameter.
* The action to delete IAM credentials is now the delete a secret version data API: DELETE /v2/secrets/{id}/versions/{version_id}/secret_data.
* Policies API is now embedded into the metadata API in version 2.0.
* The actions to list Secrets and get secret metadata return the versions_total field. The version's content is not included.
* Current and previous secret versions can be referenced by using the current and previous aliases in version APIs.
* The secret lock mode names exclusive and exclusive_delete are replaced by remove_previous and remove_previous_and delete. The modes still perform the same action, only the names changed.
* CLI commands to create secret/group/configuration require JSON input instead of param flags.
* CLI command names for configurations and locks slightly changed.



For more information, check out the [API docs](https://cloud.ibm.com/apidocs/secrets-manager/secrets-manager-v2introduction).

Now available: CLI version 2.0
: A new version of the Secrets Manager CLI is now available. For more information about the updates that are included in version 2.0, check out the [CLI change log](https://cloud.ibm.com/docs/secrets-manager?topic=secrets-manager-cli-change-log).

Deprecated: API, SDK, and CLI v1
: As of April 17, 2023, the IBM Cloud® Secrets Manager API v1 has been deprecated in favor of v2. If you're still actively working with the Secrets Manager API v1, please be sure to start your upgrade as soon as possible. On 31 October 2023, support for the Secrets Manager API v1 will be removed.





 3 March 2023 

Now available: Terraform support
: Secrets Manager now supports Terraform on IBM Cloud.
* UI
* CLI
* API
* Terraform







 Manually rotating secrets 

With IBM Cloud® Secrets Manager, you can manually create new versions of a secret by using the UI or APIs.

When you rotate a secret in your service instance, you create a new version of its value. Rotating your credentials limits how long a protected resource can be accessed by a single secret, which can protect your business against the risks that are associated with compromised credentials. Rotate your secrets regularly, for example every 30 or 60 days, so that you're always meeting best practices around secrets management.



 Before you begin 

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



 Supported secret types 

All the secrets that you store in Secrets Manager can be rotated and replaced on-demand. How Secrets Manager evaluates a request to rotate a secret depends on the secret type.



Table 1. Describes how Secrets Manager evaluates manual rotation by secret type

 Type Rotation description 

 [Arbitrary secrets](https://cloud.ibm.com/docs/secrets-manager?topic=secrets-manager-arbitrary-secrets) Arbitrary secrets are immediately replaced with the data that you provide on rotation. 
 [IAM credentials](https://cloud.ibm.com/docs/secrets-manager?topic=secrets-manager-iam-credentials) IAM credentials, which consist of a service ID and API key, are immediately regenerated according to their initial configuration. If the IAM credentials secret was created by using an existing service ID in the account, only the API key is regenerated as part of a manual rotation. In contrast, if the secret was created by selecting an access group, both the service ID and API key values are regenerated when they're manually rotated.<br><br>The Reuse IAM credentials until lease expires (reuse_api_key) option for an IAM credentials secret impacts whether it can be rotated manually. If this field is false or set to Off in the UI, manual rotation isn't supported.
"version_custom_metadata": {
"custom_version_key": "custom_version_value"
}
}'
"https://{instance_ID}.{region}.secrets-manager.appdomain.cloud/api/v2/secrets"





 Adding user credentials with Terraform 

You can store a username and password programmatically by using Terraform for Secrets Manager.

By default, Terraform detects any difference in the settings of an infrastructure object and creates a plan to update the remote object to match the configuration.

You can use the Terraform meta-argument ignore_changes when you create a resource with references to data that might change in the future, but ignore_changes does not affect the resource after you create it. With the ignore_changes meta-argument, you can specify resource attributes that Terraform ignores when it updates the associated remote object. When secrets are set to auto-rotation, Secrets Manager generates a new version of the secret with a computed new value of the password property.

The following example shows a query that you can use to create a username and password secret with auto-rotation, by using the Terraform lifecycle meta-argument ignore_changes for the password field.



1. Create the user credentials by running the following command.



resource "ibm_sm_username_password_secret" "test_username_password_secret" {
instance_id = local.instance_id
region = local.region
secret_group_id = "default"
name = "test-user-creds-secret"
username = "sm_username"
password = "sm_password"
rotation {
auto_rotate = true
interval = 10
unit = "day"
}
lifecycle {
ignore_changes = [
password,
]
}
}



2. After 10 days, the secret is auto-rotated in Secrets Manager. When you check the Terraform plan, it shows that the password field was changed outside of Terraform, as displayed in the following example.



terraform plan
data.ibm_resource_instance.sm_resource_instance: Reading...
"secret_group_id": "67d025e1-0248-418f-83ba-deb0ebfb9b4a",
"secret_type": "arbitrary",
"version_custom_metadata": {
"custom_version_key": "custom_version_value"} }' 
"https://{instance_ID}.{region}.secrets-manager.appdomain.cloud/api/v2/secrets"

A successful response returns the ID value of the secret, along with other metadata. For more information about the required and optional request parameters, check out the [API reference](https://cloud.ibm.com/apidocs/secrets-manager/secrets-manager-v2create-secret).





 Creating arbitrary secrets with Terraform 

You can create arbitrary secrets programmatically by using Terraform for Secrets Manager.

Follow Terraform best practices for protecting sensitive input variables such as secret credentials. For more information, see [Protect sensitive input variables](https://developer.hashicorp.com/terraform/tutorials/configuration-language/sensitive-variables).

The following example shows a configuration that you can use to create an arbitrary secret by setting sensitive values in a terraform.tfvars file.



1. Define an input variable for the arbitrary secret payload in a variables.tf file.



variable "arbitrary_secret_payload" {
description = "Arbitrary secret payload"
type = string
sensitive = true
}



2. Assign a value to the arbitrary_secret_payload variable in a terraform.tfvars file.

By setting values with a .tfvars file, you can separate sensitive values from the rest of your variable values, and ensure that your users who work with your configuration know which values are sensitive. For security purposes, you must maintain and share the .tfvars file only with your users who have the appropriate access. You must also be careful not to store .tfvars files with sensitive values into version control such as Github, in clear text.

arbitrary_secret_payload = "my sensitive arbitrary payload"
3.
6. Click Add.

You did it! The username and password are now stored in your dedicated, single-tenant instance of Secrets Manager.







 Step 3: Manage its lifecycle 

After you add a secret to your instance, you can establish a regular cadence for managing its lifecycle. For example, you might need to adhere to an internal requirement or regulatory control in your business for rotating secrets every 30 days.



1. In the Secrets table, click the Actions menu ![Actions icon](https://cloud.ibm.com/docs-content/v1/content/991f60ddbe3ab0a9aa69481a07a0a73b359fa329/icons/actions-icon-vertical.svg) to open a list of options for your secret.



1. To view and edit details about the secret, click Edit details.
2. To rotate the secret, click Rotate.
3. If you no longer need the secret, click Delete.









 Next steps 

Now you can add more secrets and design a secrets management strategy to control who has access to them.



* To find out more about organizing secrets, check out [Best practices for organizing secrets and assigning access](https://cloud.ibm.com/docs/secrets-manager?topic=secrets-manager-best-practices-organize-secrets).
A successful response returns the ID value for the secret, along with other metadata. For more information about the required and optional request parameters, check out the [API docs](https://cloud.ibm.com/apidocs/secrets-manager/secrets-manager-v2update-secret).





 Rotating user credentials 

You can rotate secrets by calling the Secrets Manager API.

The following example request creates a new version of your secret. 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 store metadata that are relevant to the needs of your organization with the custom_metadata and version_custom_metadata request parameters. Values of the version_custom_metadata are returned only for the versions of a secret. The custom metadata of your secret is stored as all other metadata, for up to 50 versions, and you must not include confidential data.

curl -X POST -H "Authorization: Bearer {iam_token}" -H "Accept: application/json" -H "Content-Type: application/json" -d '{
"custom_metadata": {
"metadata_custom_key": "metadata_custom_value"
},
"password": "new-password",
"version_custom_metadata": {
"custom_version_key": "custom_version_value"
}
}' 
"https://{instance_ID}.{region}.secrets-manager.appdomain.cloud/api/v2/secrets/{id}/versions"

To have the service generate and assign a random password to your credential, you can pass an empty string on the password field. For example, { "password": ""}. Secrets Manager replaces the existing value with a randomly generated 32-character password that contains uppercase letters, lowercase letters, digits, and symbols.

A successful response returns the ID value for the secret, along with other metadata.
* UI
* CLI
* API







 Locking secrets 

When you work with IBM Cloud® Secrets Manager, you can create locks on your secrets to prevent them from being deleted or modified while they're in use by your applications.

By default, an authorized user or application can modify the secrets that you manage in Secrets Manager at any time. Sometimes, for example during a security audit, you might want to prevent someone on your team from accidentally deleting a secret. Or, if you plan to rotate your secrets regularly, you might be looking for a way to safely deploy the newest version of a secret after a rotation takes place. With locks, you can build automated workflows that help you to:



* Indicate that a secret is in use by one or more applications or services.
* Prevent secret data from being deleted even after a secret expires.
* Safely delete older versions of secrets after the newest version is fully deployed to your applications.
* Avoid inadvertent downtime in your applications.



To learn about the suggested guidelines for using locks to avoid application downtime, check out [Best practices for rotating and locking secrets](https://cloud.ibm.com/docs/secrets-manager?topic=secrets-manager-best-practices-rotate-secretsbest-practices-lock-secrets).



 Before you begin 

Before you begin, be sure that you have the required level of access. To manage locks on your secrets, you need the [Manager service role](https://cloud.ibm.com/docs/secrets-manager?topic=secrets-manager-iam).





 Locking secrets 

Locking a secret prevents any operation that can result in modifying or deleting its secret data. To lock a secret, you attach one or more locks to its current or previous version.



* When you try to modify or delete a secret while it is locked, Secrets Manager denies the request with an HTTP 412 Precondition Failed response. You see an error message similar to the following example:

The requested action can't be completed because the secret version is locked.

If you're working with

dynamic secrets, such as IAM credentials, locking your secrets also means that by default, those secrets can't be read or accessed.
Working with secrets 

Learn how to work with secrets in Code Engine. In Code Engine, you can store your information as key-value pairs in secrets that can be consumed by your job or application by using environment variables.



 What are secrets and why would I use them? 

In Code Engine, secrets (and configmaps) are a collection of key-value pairs. When mapped to environment variables, the NAME=VALUE relationships are set such that the name of the environment variable corresponds to the "key" of each entry in those maps, and the value of the environment variable is the "value" of that key.

A secret provides a method to include sensitive configuration information, such as passwords or SSH keys, to your deployment. By referencing values from your secret, you can decouple sensitive information from your deployment to keep your app or job portable. Anyone who is authorized to your project can also view your secrets; be sure that you know that the secret information can be shared with those users. Secrets contain information in key-value pairs.

Because secrets and configmaps are similar entities (except secrets are stored more securely), the way you interact and work with secrets and configmaps is also similar. To learn more about configmaps, see [Working with configmaps](https://cloud.ibm.com/docs/codeengine?topic=codeengine-configmap).



 What kind of secrets can I create in Code Engine? 

Code Engine supports various secrets and provides options for creating and working with secrets.

The following table summarizes the supported secrets in Code Engine.



Table 1. Secrets in Code Engine

 Name Description 

 Basic authentication A secret that contains a username and password key. <br>Use basic authentication secrets when you access a service that requires basic HTTP authentication. 
 Generic A secret that stores simple key-value pairs and Code Engine makes no assumptions about the defined key-value pairs nor about the intended use of the secret. <br>Use generic secrets when you want to define your own key-value pairs to access a service. 
 Registry A secret that stores credentials to access a container registry.
* When you try to modify or delete a secret while it is locked, Secrets Manager denies the request with an HTTP 412 Precondition Failed response. You see an error message similar to the following example:

The requested action can't be completed because the secret version is locked.

If you're working with

dynamic secrets, such as IAM credentials, locking your secrets also means that by default, those secrets can't be read or accessed. For more information, see [Why can't I read a locked IAM credentials secret?](https://cloud.ibm.com/docs/secrets-manager?topic=secrets-manager-locked-iam-credentials)
* If a locked secret reaches its expiration date, it stays in the Active state and its data remains accessible to your applications. Secrets Manager moves the secret to the Destroyed state and permanently deletes the expired secret data only after all locks on the secret are removed.

SSL/TLS certificates still reach their defined expiration dates and move into a Destroyed state even if they are locked. For more information, see [Why did my locked certificate move to the Destroyed state?](https://cloud.ibm.com/docs/secrets-manager?topic=secrets-manager-locked-certificates)
* If you try to rotate a secret while its current version is locked and the previous version is unlocked (or if an automatic rotation is scheduled), the request to rotate the secret is allowed. The current secret version becomes the new previous version, retaining its existing locks. A new current version is created without any locks.
* If you try to rotate a secret while its previous version is locked (or if an automatic rotation is scheduled), your request to rotate the secret is denied. Rotation is allowed only after all locks on the previous secret version are removed.





 Creating locks in the UI 

You can create up to 1000 locks on a secret by using the Secrets Manager UI. Each lock can be used to represent a single application or service that uses your secret.

A secret is considered locked after you attach one or more locks to it. A lock can be applied only on a secret version that contains active payload, or secret data.
},
"version_custom_metadata": {
"custom_version_key": "custom_version_value"
}
}' 
"https://{instance_ID}.{region}.secrets-manager.appdomain.cloud/api/v2/secrets/{id}/versions"

Currently, you can restore only one version back for IAM credentials and public certificate secrets. A secret version can be restored only if the defined time-to-live (TTL) or lease duration was not reached.

A successful response returns the value of the secret, along with other metadata. For more information about the required and optional request parameters, see the [API reference](https://cloud.ibm.com/apidocs/secrets-manager).
"message":"Key Protect: rotate secret my-secret-key1",
"action":"kms.secrets.rotate",
"initiator":{
"id":"MYid-111100P9W2",
"name":"john.doe@mycompany.com",
"typeURI":"service/security/account/user",
"credential":{
"type":"token"
},
"host":{
"address": "192.0.2.0"
}
},
"target":{
"id":"crn:v1:bluemix:public:kms:us-south:a/a12333e9bd28461a8c92385628efac9f:fd692647-43d0-4699-9f83-f39a54b1327b:key:76c2c9cb-9095-5a24-811b-0ef4b24ac4d5",
"name":"my-secret-key1",
"typeURI":"kms/secrets"
},
"observer":{
"name":"ActivityTracker"
},
"reason":{
"reasonCode":204,
"reasonType":"No Content"
},
"severity":"warning",
"requestData":{
"requestURI":"/api/v2/keys/76c2c9cb-9095-5a24-811b-0ef4b24ac4d5?action=rotateu0026include_resource=true",
"instanceId":"fd692647-43d0-4699-9f83-f39a54b1327b"
},
"dataEvent":true,
"saveServiceCopy":true,
If the IAM credentials secret was created by using an existing service ID in the account, only the API key is regenerated as part of a manual rotation. In contrast, if the secret was created by selecting an access group, both the service ID and API key values are regenerated when they're manually rotated.<br><br>The Reuse IAM credentials until lease expires (reuse_api_key) option for an IAM credentials secret impacts whether it can be rotated manually. If this field is false or set to Off in the UI, manual rotation isn't supported. The API key that is dynamically generated for the secret on each read is already a single-use, ephemeral value. 
 [Imported certificates](https://cloud.ibm.com/docs/secrets-manager?topic=secrets-manager-certificatesimport-certificates) Certificates that were initially imported to a service instance are immediately replaced with the data that you reimport on rotation. 
 [Key-value secrets](https://cloud.ibm.com/docs/secrets-manager?topic=secrets-manager-key-value) Key-value secrets are immediately replaced with the data that you provide on rotation. 
 [Private certificates](https://cloud.ibm.com/docs/secrets-manager?topic=secrets-manager-certificatescreate-certificates) Private certificates are immediately replaced with a certificate that is signed by its parent or issuing certificate authority. 
 [Public certificates](https://cloud.ibm.com/docs/secrets-manager?topic=secrets-manager-certificatesorder-certificates) Public certificates move to the Active, Rotation pending status to indicate that a request to rotate a certificate is being processed. Secrets Manager sends the request to the configured certificate authority (CA), for example Let's Encrypt, to validate the ownership of your domains. If the validation completes successfully, a new certificate is issued. 
 [User credentials](https://cloud.ibm.com/docs/secrets-manager?topic=secrets-manager-user-credentials) Passwords that are associated with user credentials secrets are immediately replaced with the data that you provide on rotation. 









 Creating new secret versions in the UI