Retention policy

You can set Cloud Object Storage buckets to enforce a retention policy or period for uploaded objects, otherwise known as Immutable Object Storage. Immutable Object Storage preserves electronic records and maintains data integrity. Retention policies ensure that data is stored in a Write-One-Read-Many (WORM), nonerasable, and nonrewritable manner. You cannot change or delete objects in protected buckets within the retention period, or delete protected buckets with objects themselves until the retention period is over. The policy is enforced until the end of a retention period and the removal of any legal holds.

It is recommended that teams set a retention policy for the buckets that are used as their evidence locker that stores every object for a minimum of 365 days.

Steps to Create Service Credentials

To gain access to your COS bucket using Cloud Pipelines:

1. Navigate to Service Credentials:
   • Go to the Service Credentials section in IBM Cloud.
2. Create a New Credential:
   • Click on "Create" and follow the prompts to create a new service credential for your COS bucket.

Steps to Assign Access to COS Buckets

To assign appropriate access permissions to your COS buckets:

1. Navigate to IAM Bucket Permissions:
   • Go to the COS buckets permission section in IBM Cloud.
2. Assign Roles and Policies:
   • Assign the Reader role to CD pipelines for checking retention policies.
   • Assign the Object Writer role to CI, CD, and CC pipelines for writing evidence into buckets.

When you use the Cloud Object Storage bucket as the evidence storage, the recommended permissions are Reader and Object writer. Permissions with higher privileges (e.g., admin-level access) should be avoided to prevent accidental or malicious modification of your objects.

Sample estimation

If you are working with a reference continuous integration or continuous deployment pipeline with six evidence in each, a single continuous integration and continuous deployment run pair makes 37 class A requests and six class B requests.

• Continuous integration writes six logs, six artifacts, and six evidence, which equals 18 PUT - Class A.
• Continuous deployment reads six evidence (six GET - Class B), writes six evidence, six logs, six artifacts, and a summary, which equals 19 PUT - Class A.

With an average of five microservices (five x continuous integration) and four deployment regions (four x continuous deployment), one full deployment equals 166 Class A and 24 Class B requests.

With one full deployment per week (four per every month), you can calculate 664 Class A and 96 Class B requests per month.

The data amount that is collected varies by use-case. With average sizes for evidence (1 kB), test artifacts (100 kB), and logs (15 kB), you can calculate 0.01 GByte of data that is created and transferred per month.