vania-janet/multiturn-rag-retrieval-data huggingface dataset:
[DevSecOps CC toolchain name and region](https://cloud.ibm.com/docs-content/v1/content/5eb88a2575e30e316dbb83829c7f4c8b1ddbc67c/devsecops/images/devsecops-cc-toolchain-setup-toolchain-name-region.png)

Figure 2. DevSecOps CC toolchain name and region

You can provide a CI toolchain already setup at this step. Using filter on the region where your CI toolchain resides helps you to find it easily.

The setup fetches the resource details such as pipeline configuration, repositories like inventory and incidence issues based on the CI toolchain provided. If you chose to not provide any details for the CI toolchain details, you need to manually provide the previous details in the later steps of the setup.





 Step 3: Set up CC tool integrations 



 Secrets 

Several tools in this toolchain require secrets to access privileged resources. An IBM Cloud API key is an example of such a secret. All secrets must be stored securely in a secrets vault and then referenced as required by the toolchain.

With IBM Cloud, you can choose from various secrets management and data protection offerings that help you to protect your sensitive data and centralize your secret. In the Secrets step, you specify which secret vault integrations are added to your toolchain. Use the provided toggles to add or remove the vault integrations that you require as explained in [Managing IBM Cloud secrets](https://cloud.ibm.com/docs/secrets-manager?topic=secrets-manager-manage-secrets-ibm-cloud). This documentation gives you information on prerequisites and how to use a list of prescribed secret names that are otherwise known as hints. By using hints in a template, a toolchain can be automatically populated with preconfigured secrets without any need to manually select them from various vault integrations that are attached to the toolchain.

This tutorial uses IBM Secrets Manager as the vault for secrets.
* Org admins: When you join a consortium that is hosted by an ordering service, you provide the signing certificates of identities that will become the administrators for your organization. You can use these identities to create or edit channels.
* Peer or orderer admins: IBM Blockchain Platform nodes are deployed with the signing certificates of component administrators identities inside of them. These certificates allow the admins to operate the component from a remote client or by using the console.
* Applications: Your applications need to sign their transactions before submitting them to be validated by the network. You need to create identities you can use to sign transactions from your client applications.



You can use the console to create these identities by using the [registration process](https://cloud.ibm.com/docs/blockchain?topic=blockchain-ibp-console-identitiesibp-console-identities-register). After you register your admin identities, you need to issue each identity a signing certificate and private key, provide the signing certificate to your organization MSP definition, and add the identity to your console wallet. You can complete these steps for one admin identity when you [create your organization MSP](https://cloud.ibm.com/docs/blockchain?topic=blockchain-ibp-console-organizationsconsole-organizations-create-msp). You can use separate identities as org admins or node admins, or you can use one identity to do both tasks. The [Build a network tutorial](https://cloud.ibm.com/docs/blockchain?topic=blockchain-ibp-console-build-networkibp-console-build-network) uses one identity to be an admin for each organization created in the tutorial.





 Associating the identity of the CA admin 

Before you can create identities, you need to associate the identity of the CA admin. Open your CA on the Nodes tab. If you are using the CA for the first time, you can click the Associate identity button to generate the CA admin identity and import it into your console wallet. On the Associate identity side panel, provide the Enroll ID and Enroll secret of the CA admin that you provided when you created the CA.
KSPM can alert you to replace outdated policies with tools such as Kubernetes security contexts or custom admissions controllers.





 Validating third-party configurations 

Kubernetes is a system where teams routinely borrow or import resources from upstream. For example, you can pull container images from a public Docker Hub registry or apply a deployment file from GitHub. The third-party developers who create those resources might or might not follow the same security conventions as your own team.

KSPM offers a way of scanning third-party resources for possible security issues. In turn, you can take advantage of the rich resources that the Kubernetes community offers while also managing the associated security risks.





 Enforcing Kubernetes compliance 

Because KSPM uses policy engines to evaluate configurations and identify risks, it lends itself well to scenarios where businesses need to meet specific compliance requirements.

By writing policies that ensure that data managed or accessed by Kubernetes is stored so that it is compliant with frameworks such as HIPAA or the GDPR, you can automate compliance management.







 How does Kubernetes security posture management Work? 

Although different tools can take a different approach to KSPM, KSPM workflows include the following key steps.



 Define Security Rules 

KSPM tools are powered by policies that define security and compliance risks. Most KSPM tools come with a built-in set of policies, and admins can define their own.





 Scan configurations 

Using security and compliance rules, KSPM tools automatically scan a Kubernetes environment. For each scanned resource, configurations that violate the predefined rules are identified.

Ideally, configuration scanning takes place continuously so that risks are identified in real time whenever a new configuration is introduced or an existing one is updated.





 Detect, assess, and alert 

When a policy violation is detected, KSPM tools assess the severity level of the violation, then generates an alert or notification if the severity level merits immediate notification. Minor issues might be recorded in a log that the team can address later.





 Remediate 

When a notice of a security or compliance policy violation is received, admins investigate and remediate the problem.
About IBM Cloud Internet Services 

IBM Cloud® Internet Services, powered by Cloudflare, provides a fast, highly performant, reliable, and secure internet service for customers running their business on IBM Cloud.

IBM CIS gets you started quickly by establishing defaults for you, which you can change easily by using the UI or API.



 Clock synchronization 

ISO 27001 requires that clocks of all relevant information processing systems within an organization or security domain must be synchronized with a single reference time source. CIS synchronizes the systems with a Network Time Protocol (NTP) server to ensure that all time-based activities occur synchronously everywhere on the network.

IBM CIS uses the following internal NTP servers:



* time.adn.networklayer.com/
* time.service.networklayer.com







 Security features 

Proxy your [DNS records](https://cloud.ibm.com/docs/cis?topic=cis-dns-conceptsdns-concepts-proxying-dns-records) or a [global load balancer](https://cloud.ibm.com/docs/cis?topic=cis-global-load-balancer-glb-concepts) to use the security features. The proxy allows traffic to flow through our servers and you can monitor the data.

Zoom

![security graphic](https://cloud.ibm.com/docs-content/v1/content/cb1eb27836421578019401fa7556779109430b29/cis/images/security-graphic.png)

Figure 1. Security features



 TLS 

Protect your site and control your Transport Layer Security (TLS) settings. Manage the certificates used to secure traffic to your site.





 Origin 

Manage the TLS certificates that encrypt traffic between your origin server and your users.





 Rate limiting 

Use rate limiting rules to protect your site or API from malicious traffic by blocking client IP addresses that match a URL pattern or exceed a defined threshold.





 Traffic scrubbing 

CIS offers 192 Tbps of global network edge capacity and can mitigate DDoS attacks that have extremely high packet and HTTP request rates.
* UI
* CLI
* API







 Managing catalog settings 

As the account owner or administrator, you can manage the settings for all catalogs across your account. Management tasks include setting the visibility of the IBM Cloud® catalog and controlling access to products in the public catalog and private catalogs for users in your account.



 Before you begin 



1. Verify that you're using a Pay-As-You-Go or Subscription account. See [Viewing your account type](https://cloud.ibm.com/docs/account?topic=account-account_settingsview-acct-type) for more details.
2. Verify that you have the [administrator role on the catalog management service](https://cloud.ibm.com/docs/account?topic=account-account-servicescatalog-management-account-management).
3. If you want users to have access to products in your account, make sure that you [create a private catalog](https://cloud.ibm.com/docs/account?topic=account-restrict-by-user&interface=ui) before you update the IBM Cloud catalog visibility setting.







 Updating the visibility of the IBM Cloud catalog in the console 

Users in your account have access to all products in the public catalog by default. If you turn off the visibility of the public IBM Cloud catalog, users can't use the console to create instances of products unless you give them access to a private catalog in your account.

To update what products are visible to users, go to Manage > Catalogs > Settings in the IBM Cloud console.

Some products aren't affected by catalog visibility settings. Users can create instances of these products by using an API or the CLI. For more information, see [Known issues and limitations](https://cloud.ibm.com/docs/account?topic=account-known-issues).





 Managing access to products for all users in the console 

You can use filters to manage which products in the public catalog are available to all users in your account. For example, you might want to restrict access to third-party products. Or, you might want users to work with a specific software type.
MFT commands can be run against the Agent's queue manager.
2. In this tutorial we are using 3 different Systems. System 1 will be used to configure coordination queue manager, System 2 will be used for configuring Source Agent queue manager and System 3 will be used for configuring Destination Agent Queue manager.
3. Coordination queue manager and agent queue manager has to be connected for various communication. All the three queue managers can be connected using MQ cluster or sender/receiver channels. In this demo we are considering sender receiver channel configuration.
4. On all the system we are using profiles with administrative privileges.



NOTE : In the steps documented below, we will be creating MQ channels and MQ queues which will be used by queue managers for communicating with each other. While creating these MQ resources provide appropriate access and permissions to these objects. refer the [MQ Security Mechanism](https://www.ibm.com/support/knowledgecenter/en/SSFKSJ_9.0.0/com.ibm.mq.sec.doc/q010000_.html).

Prerequisites :

You will now create three MQ on cloud queue managers :



1. Create a new MQ on cloud queue manager, and name it as QMCOORD and download Connection Details(save this file as coordinationQMgrConnectionDetails.json). Follow the same steps(as suggested in PreRequisites step 2).
2. Create a new MQ on cloud queue manager, and name it as QMSRC and download its Connection Details(save this file as sourceAgentQMgrConnectionDetails.json). Follow the same steps(as suggested in PreRequisites step 2).
3. Create a new MQ on cloud queue manager, and name it as QMDEST and download its Connection Details(save this file as destinationAgentQMgrConnectionDetails.json). Follow the same steps(as suggested in PreRequisites step 2).
4. We are using three different Computers, we will name then as SYSTEM 1, SYSTEM 2 and SYSTEM 3.
Managing certificates 

IBM® Blockchain Platform is based on Hyperledger Fabric and builds permissioned blockchain networks. Participants are known as members of the network, and their activities and access to network resources are verified continuously. Learn how to manage a member's identity in the form of a trusted x509 digital certificate.

Target audience: This advanced topic is designed for system administrators or operators who are responsible for registering users, enrolling identities, and administering ordering services or channels. You should be familiar with Membership Service Providers (MSPs) and how they are created.

IBM Blockchain Platform manages most of the certificate operations without users needing to handle their certificates. However, there are instances when you need to manage the certificates that allow you to communicate with the network, such as for developing applications or renewing certificates before they expire. This topic is a short guide to your Certificate Authority and the underlying certificate infrastructure. This information can help you understand the certificates that you will be working with and the tasks you are responsible for.

For details on Hyperledger Fabric certificates, including certificate names, types, and locations, see the [Certificates Management Guide](https://hyperledger-fabric.readthedocs.io/en/latest/certs_management.html).



 Certificate Authorities (CAs) 

Certificate authorities (CAs) provide identity on the network. A CA can be considered as a publicly trusted notary that acts as an anchor of trust among multiple parties. All entities in the network are given a certificate that is signed by a root CA that encapsulates their digital identity. This certificate is the root of trust for all of the sign and verify operations that are performed on the network. For more details about how certificate authorities are used to establish identity, see [Hyperledger Fabric documentation](https://hyperledger-fabric.readthedocs.io/en/release-2.1/identity/identity.html).

Each organization in the network has their own CA. Your organization CA signs requests for all of the entities and components that you own, such as your admin, peers, or applications. If you want to add a node or new application to your network, you need to register the new user with your Certificate Authority (registration).
3.2.1 Ensure that a minimal audit policy is created. Automated 1 Pass 
 3.2.2 Ensure that the audit policy covers key security concerns. Manual 2 Pass 









 4 Worker nodes 

Follow the instruction in [Using the compliance operator](https://cloud.ibm.com/docs/openshift?topic=openshift-compliance-operator) to perform automated check for worker node configuration.





 5 Policies 



 5.1 RBAC and service accounts 



Section 5.1 RBAC and Service Accounts benchmark results

 Section Recommendation Manual/Automated Level Result 

 5.1.1 Ensure that the cluster-admin role is only used where required. Manual 1 Pass 
 5.1.2 Minimize access to secrets. Manual 1 Not checked 
 5.1.3 Minimize wildcard use in Roles and ClusterRoles. Manual 1 Not checked 
 5.1.4 Minimize access to create pods. Manual 1 Not checked 
 5.1.5 Ensure that default service accounts are not actively used. Automated 1 Not checked 
 5.1.6 Ensure that Service Account Tokens are mounted only where necessary. Manual 1 Not checked 







 5.2 Pod Security Policies 



Section 5.2 Pod Security Policies benchmark results

 Section Recommendation Manual/Automated Level Result 

 5.2.1 Minimize the admission of privileged containers Manual 1 Not checked 
 5.2.2 Minimize the admission of containers wanting to share the host process ID namespace Automated 1 Not checked 
 5.2.3 Minimize the admission of containers wanting to share the host IPC namespace Automated 1 Not checked 
 5.2.4 Minimize the admission of containers wanting to share the host network namespace Automated 1 Not checked 
 5.2.5 Minimize the admission of containers with allowPrivilegeEscalation. Automated 1 Not checked 
 5.2.6 Minimize the admission of root containers Manual 2 Not checked 
 5.2.7 Minimize the admission of containers with the NET_RAW capability Manual 1 Not checked
* [Channel access control lists](https://hyperledger-fabric.readthedocs.io/en/release-2.2/access_control.html) that allow you additional control of the governance of your channels and smart contracts.





OPERATE --- Total control of your deployments



* Host or join a network. Deploy peers that are hosted in your cluster to multiple channels on multiple clouds, or invite other organizations to join your consortium or channels while the organizations manage their nodes independently across infrastructures.
* Maintain complete control of your identities. Store and manage the keys that are used to administer your nodes. Optionally, use aHardware Security Module (HSM)to generate and store the private key of your nodes.
* Run Anywhere. Thanks to the unified codebase of the IBM Blockchain Platform console, it is possible to run your components on any environment supported by IBM Cloud and third-party public clouds.
* Unified operation. The IBM Blockchain Platform console allows you to deploy and manage all of your organizations and nodes in one console. You can also add or remove members from a blockchain consortium, create and join channels, and deploy smart contracts from your console.
* Dynamic signature collection that allows better control over collaborative governance over channel configurations.
* Elimination of Docker-in-Docker for smart contracts allows smart contract pods to be run more securely, without peers needing privileged access.
* Manage access of the users who can administer or monitor your nodes.
* Interact directly with your pods using the Kubernetes dashboard.
* Direct access to the logs of your nodes from your IBM Kubernetes service. Use the IBM Log Analysis or any supported third-party service to extract and analyze your logs.
* Kubernetes service integration. Leverage services such as IBM Log Analysis for logging and Prometheus and IBM Cloud Monitoring for monitoring. Leverage the built-in IBM Cloud services, such as IBM Cloud Kubernetes Service and OpenShift dashboards, IBM Log Analysis, and IBM Cloud Identity and Access Management (IAM).
* Upgrade the Fabric version of your nodes. Nodes running Fabric version 1.4.x can be [upgraded to 2.x.]
The chip can perform a limited set of cryptographic operations and is loaded with custom software. In the Management Utilities, the Smart Card Utility Program loads custom software on the smart card to create two types of smart cards:



* Certificate authority smart cards

The Certificate authority smart cards establish a set of smart cards that can work together, called a smart card zone.
* EP11 smart cards

Enterprise PKCS #11 (EP11) smart cards hold an administrator signature key and up to 85 master key parts. The custom software on an EP11 smart card includes functions for signing a command by using a private signature key that is stored on the smart card and for encrypting a master key part for delivery to a crypto unit.



Smart cards are protected by a personal identification number (PIN) that must be entered on a smart card reader PIN pad before the smart card performs the operations. The EP11 smart card has a single PIN. The certificate authority smart card has two PINs and both must be entered to enable operations.

When you use smart cards, consider the following recommendations:



* Create each master key part on a separate EP11 smart card and assign each master key part to a different person. Create backup copies of all smart cards and store them in a safe place.
* Order 10 or 12 smart cards and configure them this way:



* Create a certificate authority smart card and a backup certificate authority smart card.

A backup certificate authority smart card can be created by using the Smart Card Utility Program. Select CA Smart Card > Backup CA smart card from the menu, and follow the prompts.
* Create two EP11 smart cards and two backup EP11 smart cards to store two administrator signature keys. Generate administrator signature keys separately on two EP11 smart cards and copy them to other two backup smart cards.

The contents of an EP11 smart card can be copied to another EP11 smart card that was created in the same smart card zone by using the Trusted Key Entry application. On the Smart card tab, click Copy smart card, and follow the prompts.
* Create two EP11 smart cards and two backup EP11 smart cards to store two master key parts, or create three EP11 smart cards and three backup EP11 smart cards to store three master key parts.
All communication between the agent and Schematics is outbound from the agent and under your control.



 Schematics Agent overview 

Agents enable your Terraform and Ansible jobs to run on your private cloud network or in any isolated network zone and directly work with your cloud infrastructure. Agents extends the existing Schematics shared multi-tenant service, with private dedicated workers (agents) running Terraform and Ansible jobs on your private network. The diagram illustrates agent based job execution alongside the existing shared multi-tenant service.

Zoom

![Schematics Terraform and Ansible operations with agents](https://cloud.ibm.com/docs-content/v1/content/ba89e173287b28d1453d2a327d8a1f74ae2f1662/schematics/images/sc-agents-architecture2.svg)

Schematics Agents architecture running Terraform and Ansible

Agent assignment policies dynamically route Terraform (workspace) and Ansible (actions) jobs to execute on an agent determined by the defined policies. The default, without policies defined, is for all jobs to execute on the Schematics shared infrastructure. [Assignment policies](https://cloud.ibm.com/docs/schematics?topic=schematics-policy-manage) can be selectively defined to route jobs for workspaces and actions that meet the policy criteria to target agents and locations. Policies are defined using workspace and actions attributes, including workspace Resource Group, Schematics region and user assigned tags.

Without policy definitions, job execution is performed via the shared multi-tenant Schematics service. This is described more fully in the diagrams for the deployment architectures for [Schematics Workspaces](https://cloud.ibm.com/docs/schematics?topic=schematics-sc-workspaces) and [Schematics Actions](https://cloud.ibm.com/docs/schematics?topic=schematics-sc-actions). The shared service executes jobs on the Schematics network. To access the users private network, the shared service will require bastion host access via the public internet.