vania-janet/multiturn-rag-retrieval-data huggingface dataset:
* The hosts are assigned a public IP address but this IP address is not configured on the hosts, so they are not directly accessible on the public network.
* The second subnet is used for public access of components like a virtual gateway appliance.
* The public VLAN is intended to provide public internet access.



All subnets that are configured as part of an IBM Cloud for VMware Regulated Workloads automated deployment use IBM Cloud-managed ranges to ensure that any IP address can be routed to any data center within IBM Cloud.

Review the following table for a summary.



Table 1. VLAN and subnet summary

 VLAN Type Description 

 Public C Primary Assigned to physical hosts for public network access. 
 Private A Primary Single subnet assigned to physical hosts assigned by IBM Cloud. Used by the management interface for vSphere management traffic. 
 Private A Portable Single subnet that is assigned to VMs that function as management components 
 Private A Portable Single subnet that is assigned to NSX-T VTEP 
 Private B Portable Single subnet that is assigned for vSAN, if in use 
 Private B Portable Single subnet assigned for NAS, if in use 
 Private B Portable Single subnet assigned for vMotion 



In this design, all VLAN-backed hosts and VMs are configured to point to the perimeter gateway as the default route. While the IBM Cloud for VMware Regulated Workloads instances enable the use of SDN, network overlays created within a VMware instance that include routing to internal subnets are not known by the perimeter gateway unless dynamic routing protocols or static routes are configured.

The private network connections are configured to use a jumbo frame MTU size of 9000 to improve performance for large data transfers, such as storage and vMotion. This value is the maximum MTU that is allowed within VMware and by IBM Cloud. The public network connections use a standard ethernet MTU of 1500, which must be maintained as any changes might cause packet fragmentation over the internet.







 Related links 



* [IBM Cloud compliance programs](https://www.ibm.com/cloud/compliance)
For any request URL beginning with /generate/, we’ll replace /generate/ with /verify/, sign the resulting path with its timestamp, and return the full, signed URL using the response body.

addEventListener('fetch', event => {
const url = new URL(event.request.url)
const prefix = "/generate/"
if (url.pathname.startsWith(prefix)) {
// Replace the "/generate/" path prefix with "/verify/", which we
// use in the first example to recognize authenticated paths.
url.pathname = /verify/${url.pathname.slice(prefix.length)}
event.respondWith(generateSignedUrl(url))
} else {
event.respondWith(fetch(event.request))
}
})

async function generateSignedUrl(url) {
// We'll need some super-secret data to use as a symmetric key.
const encoder = new TextEncoder()
const secretKeyData = encoder.encode("my secret symmetric key")
const key = await crypto.subtle.importKey(
"raw", secretKeyData,
{ name: "HMAC", hash: "SHA-256" },
false, [ "sign" ]
)

// Signed requests expire after one minute. Note that you could choose
// expiration durations dynamically, depending on, e.g. the path or a query
// parameter.
const expirationMs = 60000
const expiry = Date.now() + expirationMs
const dataToAuthenticate = url.pathname + expiry

const mac = await crypto.subtle.sign(
"HMAC", key,
encoder.encode(dataToAuthenticate)
)

// mac is an ArrayBuffer, so we need to jump through a couple hoops to get
: In the volumes persistent volume claim section, enter the name of the PVC that binds the PV that you want to use.
5. Create the deployment.

kubectl apply -f <local_yaml_path>
6. Verify that the PV is successfully mounted.

kubectl describe deployment <deployment_name>

The mount point is in the Volume Mounts field and the volume is in the Volumes field.

Volume Mounts:
/var/run/secrets/kubernetes.io/serviceaccount from default-token-tqp61 (ro)
/volumemount from myvol (rw)
...
Volumes:
myvol:
Type: PersistentVolumeClaim (a reference to a PersistentVolumeClaim in the same namespace)
ClaimName: mypvc
ReadOnly: false







 Deploying an app that uses File Storage for VPC with static provisioning 

Create a persistent volume claim (PVC) to [statically provision](https://cloud.ibm.com/docs/containers?topic=containers-kube_conceptsdynamic_provisioning) File Storage for VPC for your cluster. Static provisioning allows cluster administrators to make existing storage devices available to a cluster.

Before you can create a persistent volume (PV), you have to retrieve details about your file share.



1. Get the ID for your file share.

ibmcloud is shares
2. Get the share-target.

ibmcloud is share-targets SHARE-ID
3. Get the nfsServerPath, also called the Mount Path.

ibmcloud is share-target SHARE-ID SHARE-TARGET-ID
4. Create a PV configuration file called static-file-share.yaml that references your file share.

apiVersion: v1
kind: PersistentVolume
metadata:
name: static-file-share
spec:
mountOptions:
- hard
- nfsvers=4.1
- sec=sys
accessModes:
- ReadWriteMany
capacity:
: In the volumes persistent volume claim section, enter the name of the PVC that binds the PV that you want to use.
5. Create the deployment.

oc apply -f <local_yaml_path>
6. Verify that the PV is successfully mounted.

oc describe deployment <deployment_name>

The mount point is in the Volume Mounts field and the volume is in the Volumes field.

Volume Mounts:
/var/run/secrets/kubernetes.io/serviceaccount from default-token-tqp61 (ro)
/volumemount from myvol (rw)
...
Volumes:
myvol:
Type: PersistentVolumeClaim (a reference to a PersistentVolumeClaim in the same namespace)
ClaimName: mypvc
ReadOnly: false







 Deploying an app that uses File Storage for VPC with static provisioning 

Create a persistent volume claim (PVC) to [statically provision](https://cloud.ibm.com/docs/openshift?topic=openshift-kube_conceptsdynamic_provisioning) File Storage for VPC for your cluster. Static provisioning allows cluster administrators to make existing storage devices available to a cluster.

Before you can create a persistent volume (PV), you have to retrieve details about your file share.



1. Get the ID for your file share.

ibmcloud is shares
2. Get the share-target.

ibmcloud is share-targets SHARE-ID
3. Get the nfsServerPath, also called the Mount Path.

ibmcloud is share-target SHARE-ID SHARE-TARGET-ID
4. Create a PV configuration file called static-file-share.yaml that references your file share.

apiVersion: v1
kind: PersistentVolume
metadata:
name: static-file-share
spec:
mountOptions:
- hard
- nfsvers=4.1
- sec=sys
accessModes:
- ReadWriteMany
capacity:
Table 4. 4.12 parameter reference

 Display name CLI option Type Description Required? Default value 

 OSD pod volume size osd-size Config The OSD storage size in Gi. The default value is 100Gi. true 100Gi 
 OSD pod storage class osd-storage-class Config The storage class to use when dynamically provisioning volumes for the OSD pods. true N/A 
 Number of OSD volumes num-of-osd Config The number of storage device replicas to create. The default value is 1, which creates 1 device across 3 nodes. Increase by 1 for each additional set of 3 devices. For must use cases, leave the default value of 1. true 1 
 Worker node names worker-nodes Config A comma separated list of the worker node names where you want to deploy ODF. Leave this field blank to deploy ODF across all worker nodes in your cluster. The minimum number of worker nodes is 3. You can find your worker node names by running oc get nodes. false N/A 
 Upgrade odf-upgrade Config If you are upgrading an existing ODF installation, set to true. true false 
 Billing type billing-type Config The billing type you want to use. Choose from essentials or advanced. true advanced 
 IBM COS endpoint ibm-cos-endpoint Config The IBM COS regional public endpoint. false N/A 
 IBM COS location constraint ibm-cos-location Config The location constraint that you want to use when creating your bucket. For example us-east-standard. false N/A 
 Access key ID ibm-cos-access-key Secret Your IBM COS HMAC access key ID . false N/A 
 Secret access key ibm-cos-secret-key Secret Your IBM COS HMAC secret access key. false N/A 
 Encryption enabled cluster-encryption Config Set to true if you want to enable cluster-wide encryption. true false 
 IAM API key iam-api-key Secret Your IAM API key. true N/A
"evidence_type_id": "com.ibm.dynamic_scan",
"evidence_type_version": "1.0.0",
"date": "2022-04-01T09:00:59.703Z",
"result": "failure",
"pipeline_id": "f9ab90d6-31a8-4b02-99b7-d2055ef0ee3c",
"pipeline_run_id": "9f93b02d-dbb3-4249-96e3-0739c6201779",
"toolchain_crn": "crn:v1:bluemix:public:toolchain:us-south:a/40111714589c4f7099032529b26a7a63:2618d2b8-0531-4778-9b13-9ef1a40afe29::",
"log": [
{
"hash": null,
"url": "https://cloud.ibm.com/devops/pipelines/tekton/f9ab90d6-31a8-4b02-99b7-d2055ef0ee3c/runs/9f93b02d-dbb3-4249-96e3-0739c6201779?env_id=ibm:yp:us-south"
}
],
"subject": "docker://us.icr.io/cocoa-e2e/hello-compliance-app-test:20220401083914-master-76c13d7e9fe67379f04319c8e8095b1cc623acae@sha256:090ab641c5371e48cf263119162140e3c925b8041e0220f1397528da2828a30d",
"subjects": [
* The content is streamed for the command
* One property does not have a value and =



Example:

command_with_large_output | save_repo app_ui "issues"

 this also works with multiple properties,
 but stdin can provide value for only a single one
command_with_large_output | save_repo app_ui "issues" "result=success" "commit=${REPO_SHA}"

If multiple values are missing with = the command exits with an error, because it cannot determine which property belongs to the value on stdin.

Properties without a value but still appending = have an empty string as a value.

save_repo app_ui "bar="
load_repo app_ui bar returns an empty string







 list_repos 

list_repos

Lists the <key> of the stored repos to stdout.

Example:

list_repos
 returns the list of stored repository keys to stdout for example:
 app_ui
 app_repo





 load_repo 

 <key>: Key of the repository, e.g. repository name
 <prop>: Name of the property, e.g. commit, branch, url
load_repo <key> <prop>

Prints the <prop> of repository <key> to stdout.

Example:

REPO_SHA=$(load_repo app_ui commit)

Used together with list_repos


 iterate over all repos and print their URLs

while read -r key; do
url=$(load_repo $key url)
echo "Repository saved as '$key' is at: '$url'"
done < <(list_repos)

Outputs the following lines to the console:

Repository saved as 'my-frontend' is at: 'github.com/my-team/frontend'
Repository saved as 'my-backend' is at: 'github.com/my-team/backend'





 save_result 

 <stage>: Stage name e.g. test, detect-secrets, static-scan
4. After the PVC is created, the storage plug-in tries to match the PVC to an existing PV. The PVC and the PV match when the same values for the size, IOPS, and access mode are used in the PVC and the PV. When PVC and PV match, the status of the PVC and the PV changes to Bound. You can now use the PVC to mount persistent storage to your app. When you delete the PVC, the PV and the physical storage instance are not removed. You must remove the PVC, PV, and the physical storage instance separately.



Review the following common use cases for static provisioning of persistent storage.



1. Make retained data available to the cluster: You provisioned persistent storage with a retain storage class by using dynamic provisioning. You removed the PVC, but the PV, the physical storage in IBM Cloud infrastructure, and the data still exist. You want to access the retained data from an app in your cluster.
2. Use an existing storage device: You provisioned persistent storage directly in your IBM Cloud infrastructure account and want to use this storage device in your cluster.
3. Share persistent storage across clusters in the same zone: You provisioned persistent storage for your cluster. To share the same persistent storage instance with other clusters in the same zone, you must manually create the PV and matching PVC in the other cluster. Note: Sharing persistent storage across clusters is available only if the cluster and the storage instance are located in the same zone.
4. Share persistent storage across namespaces in the same cluster: You provisioned persistent storage in a namespace of your cluster. You want to use the same storage instance for an app pod that is deployed to a different namespace in your cluster.







 Storage classes 

To dynamically provision persistent storage, you must define the type and configuration of the storage that you want.

A [Kubernetes storage class](https://kubernetes.io/docs/concepts/storage/storage-classes/) is used to abstract the underlying storage platform that is supported in IBM Cloud so that you don't have to know all the details about supported sizes, IOPS, or retention policies to successfully provision persistent storage in a cluster.
To learn about the suggested guidelines for using secret groups, check out [Best practices for organizing secrets and assigning access](https://cloud.ibm.com/docs/secrets-manager?topic=secrets-manager-best-practices-organize-secrets).



 Before you begin 

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





 Creating secret groups 

You can create secret groups by using the Secrets Manager console or the API.



 Creating secret groups in the UI 

You can create secret groups by using the console. You can also create a secret group during the process of adding or creating a secret.



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 navigation, click Secret groups > Create.
4. Add a name and description to easily identify your group.
5. Click Create.
6. Optional: Assign your secret group an [IAM policy](https://cloud.ibm.com/docs/secrets-manager?topic=secrets-manager-assign-access).







 Creating secret groups with the API 

You can create secret groups by using the Secrets Manager API.

The following example request creates a secret group. When you call the API, replace the ID variables and IAM token with the values that are specific to your Secrets Manager instance.

curl -X POST
--H "Authorization: Bearer {iam_token}" --H "Accept: application/json" --H "Content-Type: application/json" --d '{
"name":"my-secret-group",
This tutorial presents setup of a site-to-site IPSec VPN using a Virtual Router Appliance (VRA) to connect a subnet in a client data center to a secured subnet on the IBM Cloud private network.

This example builds on the [Isolate workloads with a secure private network](https://cloud.ibm.com/docs/solution-tutorials?topic=solution-tutorials-secure-network-enclosuresecure-network-enclosure) tutorial. It uses a site-to-site IPSec VPN, GRE tunnel and static routing. More complex VPN configurations that use dynamic routing (BGP etc) and VTI tunnels can be found in the [supplemental VRA documentation](https://cloud.ibm.com/docs/virtual-router-appliance?topic=virtual-router-appliance-supplemental-vra-documentationsupplemental-vra-documentation).



 Objectives 



* Document configuration parameters for IPSec VPN
* Configure IPSec VPN on a Virtual Router Appliance
* Route traffic through a GRE tunnel



Zoom

![Architecture](https://cloud.ibm.com/docs-content/v1/content/f84e2238288b7f0355715a4c355609ce7ac48fb0/solution-tutorials/images/solution36-configuring-IPSEC-VPN/sec-priv-vpn.png)

Figure 1. Architecture diagram of the tutorial



1. Document VPN Configuration
2. Create IPSec VPN on a VRA
3. Configuration of data center VPN and tunnel
4. Create GRE tunnel
5. Create static IP route
6. Configure firewall







 Before you begin
You can use common website performance tools such as [Web Page Test](https://www.webpagetest.org/) to compare the website response time before and after DCA is turned on.

After enabling DCA for a period, you can view the both static and dynamic traffic bandwidth by clicking on the View CDN report on the [CDN Overview](https://cloud.ibm.com/cdn) page.





 Step 5: Conclusion 

With DCA turned on and the detection path specified, CDN edge servers periodically fetch the test object from the origin to look for any path between the internal network of CDN edge servers that have lower latency and/or packet loss rate than the default route on the Internet. When a real request comes in, IBM® Content Delivery Network consults the most recent data to send that request over the best path to the origin.

With Prefetching enabled, DCA also finds which content is required by the application and preemptively fetches content from origin and stores it close to the user by analyzing user behavior data and web sessions. The Image compression option serves compressed images to reduces the amount of content required to load a page, especially when end users have slow network speed. DCA also employs TCP-layer optimizations that accelerate connection set up and reduce round trips.





 Step 6: Remove resources 



* Delete the application from the [Kubernetes Service](https://cloud.ibm.com/kubernetes/clusters).
* Delete the image from the [Container Registry](https://cloud.ibm.com/registry/images).
* Delete the [IBM® Content Delivery Network service](https://cloud.ibm.com/classic/network/cdn).







 Related content 



* [Getting Started with CDN](https://cloud.ibm.com/docs/CDN?topic=CDN-getting-startedgetting-started)
* [IBM Cloud Kubernetes Service](https://cloud.ibm.com/docs/containers)
* [IBM Cloud Container Registry](https://cloud.ibm.com/docs/Registry?topic=Registry-getting-startedgetting-started)
set protocols static route {{ ibm_vpc_cidr }} next-hop 169.254.0.1 distance 10
set protocols static route {{ ibm_vpc_cidr }} next-hop 169.254.0.1 interface vti1
5. Create the VTI and VPN connection to the IBM secondary tunnel:

set interfaces vti vti2 description "to-IBM-VPN-secondary"
set interfaces vti vti2 address 169.254.0.6/30
set interfaces vti vti2 ip tcp-mss limit 1360
set security vpn ipsec site-to-site peer {{ secondary_peer_address }} authentication mode pre-shared-secret
set security vpn ipsec site-to-site peer {{ secondary_peer_address }} authentication pre-shared-secret {{your_pre_shared_key}}
set security vpn ipsec site-to-site peer {{ secondary_peer_address }} ike-group ibm-vpc-ike-group
set security vpn ipsec site-to-site peer {{ secondary_peer_address }} default-esp-group ibm-vpc-ipsec-group
set security vpn ipsec site-to-site peer {{ secondary_peer_address }} description "to-IBM-VPN-secondary"
set security vpn ipsec site-to-site peer {{ secondary_peer_address }} local-address {{ vyatta_address }}
set security vpn ipsec site-to-site peer {{ secondary_peer_address }} connection-type initiate
set security vpn ipsec site-to-site peer {{ secondary_peer_address }} authentication remote-id {{ secondary_peer_address }}
set security vpn ipsec site-to-site peer {{ secondary_peer_address }} vti bind vti2
Show more

The VTI IP address 169.254.0.6 is an example. You can use any other unused IP address.
6. Create the primary route:
Agile and DevOps provide for automation and greater development velocity, software quality, and consistency and reliability in the delivery processes while they remove the potential for human error. DevSecOps integrates a set of security and compliance controls into the DevOps processes. This feature allows organizations to deliver rapidly and often while they maintain a strong security posture and continuous state of audit-readiness.

Like Agile and DevOps, DevSecOps introduces a culture change and removes the traditional barriers between Developers, Operations, and Security and Compliance officers. Development teams take greater ownership of security rather than relying on external teams to evaluate their software for security, often late in the development cycle when discovered vulnerabilities are more disruptive and expensive to remediate. The old model of having a siloed security team does not scale and does not meet the needs of a development project in a cloud-native DevOps domain. With DevSecOps, a security team's purpose evolves to more of a supportive, advising, and governance role.

With DevSecOps, developers can continue to deliver updates frequently with a minimal amount of friction. Integration of automated security scans and controls into the DevOps pipelines provides confidence with evidence to the change management process. This integration also supports automated approvals of new deployments to production when all secure criteria are met and specific checks pass. Introducing security and compliance early into the development and deployment process reduces costs and risk by identifying problems early before the software reaches a production environment. This approach is often referred to as "shift-left". Moreover, even if secure best practices are part of the training in every organization, developers might lack deep expertise at the security level. Applying DevSecOps and shift-left to the delivery lifecycle reduces the risk of naively releasing known vulnerabilities into production.

Organizations can take advantage of the significant benefits of using a standard set of processes for continuous integration and continuous delivery by multiple disparate teams that develop heterogeneous offerings and components. These benefits include consistency and economies of scales. When a single set of prescriptive reference pipelines that are instrumented for compliance are used for all of the components across an organization, developers spend less time to develop automation solutions and can focus on feature development.
RA-3 - Risk Assessment 



 Control requirements 

The organization:

RA-3 (a)
: Conducts an assessment of risk, including the likelihood and magnitude of harm, from the unauthorized access, use, disclosure, disruption, modification, or destruction of the information system and the information it processes, stores, or transmits;

RA-3 (b)
: Documents risk assessment results in [IBM Assignment: security assessment report];

RA-3 (c)
: Reviews risk assessment results [IBM Assignment: at least annually, when a significant change occurs, or when threats evolve];

RA-3 (d)
: Disseminates risk assessment results to [Assignment: organization-defined personnel or roles]; and

RA-3 (e)
: Updates the risk assessment [IBM Assignment: at least annually] or whenever there are significant changes to the information system or environment of operation (including the identification of new threats and vulnerabilities), or other conditions that may impact the security state of the system.





 Additional IBM Cloud for Financial Services specifications 



* The organization shall conduct a risk assessment identifying all applicable threats to the organization portion of the FS-ready public cloud. Risk assessment methodology shall adhere to the guidance contained in NIST Special Publication 800-30, Revision 1, Guide for Conducting Risk Assessments.







 NIST supplemental guidance 

Clearly defined authorization boundaries are a prerequisite for effective risk assessments. Risk assessments take into account threats, vulnerabilities, likelihood, and impact to organizational operations and assets, individuals, other organizations, and the Nation based on the operation and use of information systems. Risk assessments also take into account risk from external parties (e.g., service providers, contractors operating information systems on behalf of the organization, individuals accessing organizational information systems, outsourcing entities). In accordance with OMB policy and related E-authentication initiatives, authentication of public users accessing federal information systems may also be required to protect nonpublic or privacy-related information. As such, organizational assessments of risk also address public access to federal information systems.