vania-janet/multiturn-rag-retrieval-data huggingface dataset:
Running secure enterprise workloads on IBM Cloud 

With continuous compliance at the core of IBM Cloud®'s platform, your team has all of the tools at your disposal to securely develop, deploy, and manage your regulated, mission-critical enterprise workloads in the cloud.

For highly regulated industries, such as financial services, achieving continuous compliance within a cloud environment is an important first step toward protecting customer and application data. Historically, that process has been difficult and manual, which placed your organization at risk. But, with IBM Cloud you can work with predefined deployable architectures, automate infrastructure-as-code deployments with

projects, and integrate automatic security checks into every day workflows to minimize risk.

With IBM Cloud, your whole team from solution architects, compliance managers, infrastructure DevOps teams, to application development teams can use a shift-left approach to identify security risks and exposures early when developing and deploying cloud solutions. This keeps security and compliance at the center of your workflow and organizational culture so that your enterprise can operate in the cloud with confidence. Check out the following video to learn more about how IBM Cloud can help you accelerate and maintain your regulated standards at scale.



* Video transcript

Hi, I’m Mark Meredith a product manager for IBM Cloud.

As a large enterprise your requirements for scale, security, infrastructure, and governance all influence your move to the cloud.

With the tools available through IBM Cloud, you can start and stay compliant, use automation, and ensure deployments are done by using a secure software supply chain, all while managing your resources at scale.

Creating secure, compliant, robust, and scalable application infrastructure can be difficult to set up and costly to maintain.

But, if you standardize application infrastructure where possible and then host many applications on the same infrastructure you can reduce operations costs.

You can do this with deployable architectures and projects on IBM Cloud.

With our growing catalog of deployable architectures you can quickly get started by adding it to a project and customizing it to your needs.

Projects aren’t just for configuring your solution though. Projects also enable you to organize resources by what you care about in your organization, whether it’s by application or business unit, to get helpful views into cost, availability, and compliance.
After a successful cluster deployment, you won't be able to SSH to the nodes due to the following issues:

 Why it’s happening 



1. SSH keys were not properly installed on the virtual server instance during the automation process.
2. The wrong SSH key names were used. For example, SSH key names that aren't owned by the individual trying to establish SSH connection were used.
3. The security group doesn't have the appropriate source range.



You can try the following procedures to help troubleshoot the SSH issue:

 How to fix it 



1. Ensure that you have the correct IP address to establish SSH connection. Refresh the UI to fetch the latest IP address details.
2. Check whether the SSH connection works for the bastion host (for example, `ssh ubuntu@ ). If the connection is successful, then you can troubleshoot the SSH issue for the other nodes.
3. Open the security group of the bastion host and check if TCP port 22 with source range is open from the user machine.
4. Use [https://ipv4.icanhazip.com/](https://ipv4.icanhazip.com/) to fetch the current IP address and validate whether there is a different, updated IP address on the security group of the source address range.
5. Open the security group of the bootstrap, compute, and storage nodes to see the bastion node security group source details to access SSH to connect to the other nodes.
6. Make sure that the public SSH key that's used in the region matches the id_rsa.pub content from the local machine. Use the commands cd .ssh and cat id_rsa.pub to check.
7. Ensure that there are no duplicate id_rsa.pub files present in the .ssh folder in the local machine.







 What is the subnet_not_in_address_prefix error or invalid CIDR format error during the VPC and subnet creation? 

 What’s happening
Certificate Authority (CA) patch 1.5.3-3, Peer and ordering node patch 1.4.12-14, 2.2.5-6, 2.4.3-3.

Miscellaneous bug fixes and security patches.

Severity: medium





 01 June 2022 

Certificate Authority (CA) patch 1.5.3-2, Peer and ordering node patch 1.4.12-13, 2.2.5-5, 2.4.3-2.

Miscellaneous bug fixes and security patches.

Severity: medium





 03 May 2022 

Certificate Authority (CA) patch 1.5.3-1, Peer and ordering node patch 1.4.12-12, 2.2.5-4, 2.4.3-1.

v2.5.4 release updates listed in [What's new](https://cloud.ibm.com/docs/blockchain?topic=blockchain-whats-new) for May 03, 2022.

Miscellaneous bug fixes and security patches.

Severity: medium





 05 Apr 2022 

Certificate Authority (CA) patch 1.5.2-8, Peer and ordering node patch 1.4.12-11, 2.2.5-3.

Miscellaneous bug fixes and security patches.

Severity: medium





 08 Mar 2022 

Certificate Authority (CA) patch 1.5.2-7, Peer and ordering node patch 1.4.12-10, 2.2.5-2.

Miscellaneous bug fixes and security patches.

Severity: medium





 08 Feb 2022 

Certificate Authority (CA) patch 1.5.2-6, Peer and ordering node patch 1.4.12-9, 2.2.5-1.

Miscellaneous bug fixes and security patches.

Severity: medium





 11 Jan 2022 

Certificate Authority (CA) patch 1.5.2-5, Peer and ordering node patch 1.4.12-8, 2.2.4-5.

Miscellaneous bug fixes and security patches.





 14 Dec 2021
Manage access to toolchains in resource groups and their associated IBM-hosted tools, except for Git Repos and Issue Tracking. N/A Grant, revoke, and manage access to toolchains by using IBM Cloud Identity and Access Management (IAM). For more information about access management, see [Managing user access to toolchains in resource groups](https://cloud.ibm.com/docs/services/ContinuousDelivery?topic=ContinuousDelivery-toolchains-iam-security). 
 Manage the Continuous Delivery service's access to third-party tools that are integrated into toolchains. N/A Add, update, or delete third-party tool integration configurations (including access credentials for tool integrations) in toolchains. For more information about working with tool integrations, see [Configuring tool integrations](https://cloud.ibm.com/docs/services/ContinuousDelivery?topic=ContinuousDelivery-integrations). 
 Manage access to repos in Git Repos and Issue Tracking. N/A From the Settings > Members page in the Git Repos and Issue Tracking dashboard, manage project members and role permissions. 
 Manage all other access to third-party tools that are integrated with Continuous Delivery. N/A Manage access by using the capabilities that are provided by the third-party tools. 







 Security and regulation compliance 

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



Table 4. Responsibilities for security and regulation compliance

 Task IBM responsibilities Your responsibilities 

 Meet security and compliance objectives Provide a secure Continuous Delivery service that complies with key standards. For more information about data security, see [How do I know that my data is safe?](https://cloud.ibm.com/docs/overview/terms-of-use?topic=overview-security) Secure your workloads and data. Integrate tools into your toolchains that satisfy your security and compliance requirements. To learn more about securing your cloud apps, see [Security to safeguard and monitor your cloud apps](https://www.ibm.com/cloud/garage/architectures/securityArchitecture).
8. Optional: Attach interfaces, bare metal interfaces, load balancers, virtual private endpoint gateways, and VPN servers in the remaining sections if these targets are available to attach.







 Setting up the security groups for your resource from the CLI 

In this example, you create a virtual server instance with a security group that is enabled by using the command-line interface (CLI). Figure 1 shows what this scenario looks like.

Zoom

![Figure showing a virtual server instance with a security group enabled](https://cloud.ibm.com/docs-content/v1/content/f02b9c9adcbb7328d95a45e105cec371d50f15eb/vpc//images/security-groups-schematic.svg)

Figure 1. Instance with security group enabled

Notice in Figure 1 that the instance named SG4 has the floating IP 169.60.208.144 assigned to it, in addition to its internal VPC address 10.10.10.5; therefore, SG4 can talk to the public internet. The security group assigned to instance SG4 is named demosg.

The instance SG8 is internal-only to the VPC, with a private IP address. The security group assigned to instance SG8 is named my_vpc_sg. Both of these instances exist within the VPC named sgvpc and also on the same subnet 10.10.10.0/24 so they can communicate with each other.



 Creating a resource with a security group attached 

The security group rules for my_vpc_sg include the basic functions of SSH, PING, and outbound TCP.

Notice that you must create the security group first, with the ibmcloud is sgc command, and then create the resource that uses this security group.

You must enter ibmcloud plugin install vpc-infrastructure to get access to ibmcloud is.
Responsibilities when you use Hyper Protect Virtual Servers 

Learn about management responsibilities and terms and conditions that you must observe when you use IBM Cloud® Hyper Protect Virtual Servers.



 Management responsibilities 

IBM provides you with an enterprise cloud platform to deploy your workload. You choose how to set up, integrate, back up, and operate your workloads in the cloud.



 Cloud Infrastructure 

IBM's responsibilities:



* Deploy a fully managed, reliable, secured, IBM-owned infrastructure.
* Fulfill requests for Hyper Protect Virtual Servers across multiple data centers.



Your responsibilities:



* Take the required actions on regular maintenance notification from IBM.
* Use the provided UI console to provision compute and storage to meet the needs of your workload.
* Design and deploy your workload in a way that achieves high availability by using multiple data centers.







 Hyper Protect Virtual Servers 

IBM's responsibilities:



* Set up virtual servers as requested.
* Update the OS kernel.



Your responsibilities:



* Maintain OS patches, version updates, and security updates.
* Set up your backup and recovery strategies for workload data.
* Monitor the health of your workload.







 Security-rich Environment 

IBM's responsibilities:



* Maintain controls commensurate to current industry compliance standards.
* Enable security features, such as encrypted disks.
* Continuously monitor stock images to detect vulnerability and security compliance issues.
* Use the IBM Cloud® user interface and CLI for authentication and authorization for the Hyper Protect Virtual Servers offering.



Your responsibilities:



* Use security groups and network ACLs to secure your virtual server instances, such as restricting what IP addresses can SSH into the instance.
* Choose how to connect your workload to the public internet.
* Restrict user access to the appropriate resources and resource groups.
* Recommend to enable the SSH Host key checking or specify the StrictHostKeyChecking = yes in the ssh_config file for additional security to allow only verified known hosts to connect to the instance.







 App Orchestration 

IBM's responsibilities:



* None.



Your responsibilities:



* Use the tools and features that are provided to:



* Configure and deploy setup permissions.
* Integrate with other services.
If you modify the default VPC security groups, you must, at minimum, include the required [inbound](https://cloud.ibm.com/docs/containers?topic=containers-vpc-security-groupmin-outbound-rules-sg-workers) and [outbound](https://cloud.ibm.com/docs/containers?topic=containers-vpc-security-groupmin-inbound-rules-sg-workers) rules so that your cluster works properly.



 Security groups applied to cluster workers 

Do not modify the rules in thekube-<cluster-ID> security group as doing so might cause disruptions in network connectivity between the workers of the cluster and the control cluster. However, if you don't want the kube-<cluster-ID>, you can instead add your own security groups during [cluster creation](https://cloud.ibm.com/docs/containers?topic=containers-cluster-create-vpc-gen2&interface=clicluster_vpcg2_cli).



Table 1. VPC security groups
The table shows the three types of security groups that are automatically created for VPCs. The first column includes the type of security group. The second column includes the naming format of the security group. The third column includes details on when and where the security group is created and what type of traffic it allows.

 Security group type Name Details 

 VPC security group Randomly generated <br><br> * Automatically created when the VPC is created. Automatically attached to each worker node in a cluster created in the VPC.<br> * Allows all outbound traffic by default.<br><br><br> 
 VPC cluster security group kube-<cluster-ID> <br><br> * Automatically created when the VPC cluster is created. Automatically attached to each worker node in a cluster created in the VPC.<br> * Allows traffic necessary for the cluster infrastructure to function.<br><br><br> 







 Security groups applied to VPE gateways and VPC ALBs
If you modify the default VPC security groups, you must, at minimum, include the required [inbound](https://cloud.ibm.com/docs/openshift?topic=openshift-vpc-security-groupmin-outbound-rules-sg-workers) and [outbound](https://cloud.ibm.com/docs/openshift?topic=openshift-vpc-security-groupmin-inbound-rules-sg-workers) rules so that your cluster works properly.



 Security groups applied to cluster workers 

Do not modify the rules in thekube-<cluster-ID> security group as doing so might cause disruptions in network connectivity between the workers of the cluster and the control cluster. However, if you don't want the kube-<cluster-ID>, you can instead add your own security groups during [cluster creation](https://cloud.ibm.com/docs/openshift?topic=openshift-cluster-create-vpc-gen2&interface=ui).



Table 1. VPC security groups
The table shows the three types of security groups that are automatically created for VPCs. The first column includes the type of security group. The second column includes the naming format of the security group. The third column includes details on when and where the security group is created and what type of traffic it allows.

 Security group type Name Details 

 VPC security group Randomly generated <br><br> * Automatically created when the VPC is created. Automatically attached to each worker node in a cluster created in the VPC.<br> * Allows all outbound traffic by default.<br><br><br> 
 VPC cluster security group kube-<cluster-ID> <br><br> * Automatically created when the VPC cluster is created. Automatically attached to each worker node in a cluster created in the VPC.<br> * Allows traffic necessary for the cluster infrastructure to function.<br><br><br> 







 Security groups applied to VPE gateways and VPC ALBs
Security groups 

With security groups for IBM Cloud® Virtual Servers, you can enact a set of IP filter rules that define how to handle incoming and outgoing traffic to both the public and private interfaces of a virtual server. A security group creates a type of virtual firewall.

For more information about security groups, see [Getting started with security groups](https://cloud.ibm.com/docs/security-groups?topic=security-groups-getting-started).
If prompted, insert an EP11 smart card with an administrator signature key that is defined to the selected crypto units in smart card reader 1. And then, enter the smart card PIN on the smart card reader PIN pad.



The crypto units in the current master key register is now in Valid status, which indicates that your master key is loaded to your service instance.

If you want to clear your current master key in a later phase, click Clear current.









 What's next 



* Go to the KMS keys tab of your instance dashboard to [manage root keys and standard keys](https://cloud.ibm.com/docs/hs-crypto?topic=hs-crypto-get-startedmanage-keys). To find out more about programmatically managing your keys, check out the Hyper Protect Crypto Services [key management service API reference doc](https://cloud.ibm.com/apidocs/hs-crypto).
* To learn more about performing cryptographic operations with the cloud HSM, see [Introducing cloud HSM](https://cloud.ibm.com/docs/hs-crypto?topic=hs-crypto-introduce-cloud-hsm).
* Use Hyper Protect Crypto Services as the root key provider for other IBM Cloud services. For more information about integrating Hyper Protect Crypto Services, check out [Integrating services](https://cloud.ibm.com/docs/hs-crypto?topic=hs-crypto-integrate-services).
* Read [Hyper Protect Crypto Services cloud TKE procedures](https://cloud.ibm.com/docs/hs-crypto?topic=hs-crypto-tke-procedures) for a template with procedures for the secure initialization and management of IBM Cloud® Hyper Protect Crypto Services Enterprise PKCS#11 Hardware Security Modules using Cloud Trusted Key Entry (TKE) and smart cards.
If your application requires lower latency and higher IOPs, use a virtual server with block volumes. You need a 3rd-party tool to provide replication or snapshots. For unstructured data and high data volumes, use Object Storage. The IBM Cloud Object Storage service has different tiers where replication varies such as within a zone, across multiple zones, or across regions. The replication is not instantaneous, but occurs over time.





 Security 

IBM Cloud provides both security groups and firewall access control lists (ACL). For host-based security, consider using security groups to preserve the firewall ACLs. Firewall ACLs are best used when they are applying the same security rule at a subnet level rather than at the host level.







 VSI Considerations 



 Placement groups 

Creating multiple instances of the same type gives you 2 things:



1. Removes a single point of failure. If one instance goes down, then other instances are available to pick up the work and continue the service.
2. Increases capacity. Parallelism allows multiple workers for higher output.



When you create multiple instances, the VSI scheduler makes every effort to place the VSIs on different hypervisors. And all hypervisors are installed on highly available servers (for example, redundant power supply, redundant network connections). Even with all of these guard rails in place, there is still a possibility for a single point of failure if somehow all your VSIs are deployed on the same hypervisor. A system crash will take down all your VSIs. So, creating multiple VSIs may not improve your resiliency as much as you would like or hope.

Spreading the VSIs across the zones does address this risk but what about multiple VSIs that are in the same zone? For example, suppose you have 5 VSIs that are dedicated to your web tier and are spread across three zones; 2 of the 3 zones have 2 VSIs. You want to ensure that the zones that have 2 VSIs are set up for the best availability. Granted you have other zones to protect you against failure in a zone, but it would be better to ensure the 2 VSIs are created on different hypervisors.
If you modify the default VPC security groups, you must, at minimum, include the required [inbound](https://cloud.ibm.com/docs/containers?topic=containers-vpc-security-group&interface=uimin-outbound-rules-sg-workers) and [outbound](https://cloud.ibm.com/docs/containers?topic=containers-vpc-security-group&interface=uimin-inbound-rules-sg-workers) rules so that your cluster works properly.



 Security groups applied to cluster workers 

Do not modify the rules in thekube-<cluster-ID> security group as doing so might cause disruptions in network connectivity between the workers of the cluster and the control cluster. However, if you don't want the kube-<cluster-ID>, you can instead add your own security groups during [cluster creation](https://cloud.ibm.com/docs/containers?topic=containers-cluster-create-vpc-gen2&interface=clicluster_vpcg2_cli).



Table 1. VPC security groups
The table shows the three types of security groups that are automatically created for VPCs. The first column includes the type of security group. The second column includes the naming format of the security group. The third column includes details on when and where the security group is created and what type of traffic it allows.

 Security group type Name Details 

 VPC security group Randomly generated <br><br> * Automatically created when the VPC is created. Automatically attached to each worker node in a cluster created in the VPC.<br> * Allows all outbound traffic by default.<br><br><br> 
 VPC cluster security group kube-<cluster-ID> <br><br> * Automatically created when the VPC cluster is created. Automatically attached to each worker node in a cluster created in the VPC.<br> * Allows traffic necessary for the cluster infrastructure to function.<br><br><br> 







 Security groups applied to VPE gateways and VPC ALBs
* Offering: select your Db2 Warehouse on Cloud instance
* Subject: VPN Connection Request
* Description: provide the following required information
* Customer-side VPN Peer Address (your VPN endpoint): 
* Customer-side Encryption Domain (be specific about what is required – 10.0.0.0/8 is unworkable because 10 addressing is also used within the IBM Cloud for back-end services): 
* Customer-side VPN Hardware & Version: 
* Customer-side VPN Contact (technical contact name and email address):
* 
* 
* <email address>

Optional (change only if the following default values are not suitable):

IKE/ISAKMP Parameters (Phase I)

* Encryption Method: IKEv1
* IKE Encryption / Encryption Algorithm: AES-256
* Authentication Algorithm: SHA1
* DH-Group: Group 5
* Security Association Lifetime (seconds): 1d (86400 seconds)

IPSec Parameters (Phase II)

* IPSec Encryption / Encryption Algorithm: AES-256
* Authentication Algorithm: SHA1
* DH-Group (if using PF-Secrecy): Group 5
* Security Association Lifetime (seconds): 3600 seconds

After receipt of your request, IBM Cloud technicians will open the appropriate firewall ports and allowlist the provided IP address. Communication and resolution to the request is made through the IBM Cloud Support case ticket.

(images/public_connection.png "Graphical representation of user to cloud connection"){: caption="Figure 1. Public network access to IBM Cloud" caption-side="bottom"}Public network access to IBM Cloud through a VPN]