vania-janet/multiturn-rag-retrieval-data huggingface dataset:
Certificate manager actions

 Action Description 

 hs-crypto.mtlscert-admin-key.create Create the administrator signature key for the certificate administrator to connect to the certificate manager server. 
 hs-crypto.mtlscert-admin-key.update Refresh and update the administrator signature key for the certificate administrator. 
 hs-crypto.mtlscert-admin-key.read Get the administrator signature key of the certificate administrator. 
 hs-crypto.mtlscert-admin-key.delete Delete the administrator signature key of the certificate administrator. 
 hs-crypto.mtlscert-cert.set Create or update certificates by the certificate administrator. 
 hs-crypto.mtlscert-cert.list List all certificates that are managed by the certificate administrator. 
 hs-crypto.mtlscert-cert.read Get certificates by the certificate administrator. 
 hs-crypto.mtlscert-cert.delete Delete certificates by the certificate administrator. 







 KMIP for VMware events 

When you manage keys for the KMIP for VMware® service, an event is generated.

The following table provides the actions that generate and send events for KMIP for VMware. These actions are performed by an initiator from VMware vCenter Server® and do not include the initiator's IP address. The requests for these actions run from within the IBM Cloud private network.

The initiator ID is derived from the TLS (Transport Layer Security) certificate of the vCenter Server that is used to authenticate the connection to the KMIP server. The initiator ID is in the format CertificateID-<value>, where the value matches the fingerprint of the corresponding TLS certificate. Using the fingerprint, you can identify the vCenter Server that triggered the action.



Table 9. Description of actions that generate events for the KMIP for VMware service

 Action Description 

 hs-crypto.kmip-key.create A KMIP key is created. 
 hs-crypto.kmip-key.read A KMIP key is retrieved.
Certificate manager actions

 Action Description 

 hs-crypto.mtlscert-admin-key.create Create the administrator signature key for the certificate administrator to connect to the certificate manager server. 
 hs-crypto.mtlscert-admin-key.update Refresh and update the administrator signature key for the certificate administrator. 
 hs-crypto.mtlscert-admin-key.read Get the administrator signature key of the certificate administrator. 
 hs-crypto.mtlscert-admin-key.delete Delete the administrator signature key of the certificate administrator. 
 hs-crypto.mtlscert-cert.set Create or update certificates by the certificate administrator. 
 hs-crypto.mtlscert-cert.list List all certificates that are managed by the certificate administrator. 
 hs-crypto.mtlscert-cert.read Get certificates by the certificate administrator. 
 hs-crypto.mtlscert-cert.delete Delete certificates by the certificate administrator. 







 KMIP for VMware events 

When you manage keys for the KMIP for VMware® service, an event is generated.

The following table provides the actions that generate and send events for KMIP for VMware. These actions are performed by an initiator from VMware vCenter Server® and do not include the initiator's IP address. The requests for these actions run from within the IBM Cloud private network.

The initiator ID is derived from the TLS (Transport Layer Security) certificate of the vCenter Server that is used to authenticate the connection to the KMIP server. The initiator ID is in the format CertificateID-<value>, where the value matches the fingerprint of the corresponding TLS certificate. Using the fingerprint, you can identify the vCenter Server that triggered the action.



Table 8. Description of actions that generate events for the KMIP for VMware service

 Action Description 

 hs-crypto.kmip-key.create A KMIP key is created. 
 hs-crypto.kmip-key.read A KMIP key is retrieved.
Regions and endpoints 

Review region and connectivity options for interacting with IBM Cloud® Continuous Delivery.



 Available regions 

Continuous Delivery is available in the following regions (borders and geographic features in the illustration are artistic representations):

Zoom

![Regions where the Continuous Delivery service is available.](https://cloud.ibm.com/docs-content/v1/content/562806c0b18119f4d21cb66f5ae6d051634b4a16/ContinuousDelivery/images/world-map.svg)

Figure 1. Displays the regions where you can create and manage Continuous Delivery resources.

You can create Continuous Delivery resources, including toolchains, in one of the supported IBM Cloud regions, which represent the geographic area where your Continuous Delivery requests are handled and processed. To learn more, see [Continuous Delivery high availability and disaster recovery](https://cloud.ibm.com/docs/ContinuousDelivery?topic=ContinuousDelivery-ha-dr).





 Service endpoints 

Continuous Delivery offers two connectivity options for interacting with its service APIs: public endpoints (available in all regions) and private endpoints (available in selected regions).



 Public endpoints 

By default, you can connect to resources in your account over the IBM Cloud public network. Your data is encrypted in transit by using supported ciphers of the Transport Security Layer (TLS) 1.2 and 1.3 protocol. For more information about TLS and these ciphers, see [Securing your data in Continuous Delivery](https://cloud.ibm.com/docs/ContinuousDelivery?topic=ContinuousDelivery-cd_data_security).

Review the following table to determine the public API endpoints to use when you connect to the [Continuous Delivery API](https://cloud.ibm.com/docs?tab=api-docs&category=devops&subCategory=ContinuousDelivery).



Table 1. Public endpoints for interacting with Continuous Delivery APIs over IBM Cloud's public network

 Region Public endpoints 

 Dallas us-south.devops.cloud.ibm.com
Architecture pattern for using Direct Link with NSX-T and EVPN 

On [VMware vCenter Server](https://cloud.ibm.com/docs/vmwaresolutions?topic=vmwaresolutions-vc_vcenterserveroverview) instance in IBM Cloud® classic infrastructure, your workloads are deployed and run on VMware NSX-T™ overlay networks. As part of the deployment, the automation deploys an example NSX-T topology. You can use the provisioned examples as your base or build your own topologies on overlay. These overlay networks are not automatically advertised to IBM Cloud classic infrastructure network.

This architecture pattern presents private connectivity for VMware vCenter Server® that uses [Direct Link](https://cloud.ibm.com/docs/dl) and EVPN. EVPN (Ethernet VPN) is a standards-based BGP control plane that extends Layer 2 and Layer 3 connectivity between different data centers. Multi-Protocol BGP (MP-BGP) EVPN is established between NSX-T T0 and a Customer Router through Direct Link. IBM Cloud private network and Direct Link are used as L3 transport network for VXLAN traffic. VXLAN is the used encapsulation between NSX-T and the Customer Router.

You can use Gateway Appliance or vCenter Server gateway cluster with Juniper vSRX or other device as part of the solution. This is optional.



 Deploying Direct Link with NSX-T and EVPN 

The following diagram presents an overview for an architecture pattern for using Direct Link with NSX-T and EVPN.

Zoom

![Direct Link with NSX-T and EVPN](https://cloud.ibm.com/docs-content/v1/content/5bdb37c0149145723c5437e8176651928565e722/vmwaresolutions/images/arch-pattern-vcs-nsx-t-direct-link-evpn.svg)

Figure 1. Direct Link with NSX-T and EVPN
MP-5 - Media Transport 



  Control requirements 

The organization:

MP-5 (a)
:   Protects and controls [IBM Assignment: all media with sensitive information] during transport outside of controlled areas using [IBM Assignment: for digital media, encryption using a FIPS 140-2 validated encryption module; for non-digital media, secured in locked container];

MP-5 (b)
:   Maintains accountability for information system media during transport outside of controlled areas;

MP-5 (c)
:   Documents activities associated with the transport of information system media; and

MP-5 (d)
:   Restricts the activities associated with the transport of information system media to authorized personnel.





  NIST supplemental guidance 

Information system media includes both digital and non-digital media. Digital media includes, for example, diskettes, magnetic tapes, external/removable hard disk drives, flash drives, compact disks, and digital video disks. Non-digital media includes, for example, paper and microfilm. This control also applies to mobile devices with information storage capability (e.g., smart phones, tablets, E-readers), that are transported outside of controlled areas. Controlled areas are areas or spaces for which organizations provide sufficient physical and/or procedural safeguards to meet the requirements established for protecting information and/or information systems. Physical and technical safeguards for media are commensurate with the security category or classification of the information residing on the media. Safeguards to protect media during transport include, for example, locked containers and cryptography. Cryptographic mechanisms can provide confidentiality and integrity protections depending upon the mechanisms used. Activities associated with transport include the actual transport as well as those activities such as releasing media for transport and ensuring that media enters the appropriate transport processes. For the actual transport, authorized transport and courier personnel may include individuals from outside the organization (e.g., U.S. Postal Service or a commercial transport or delivery service). Maintaining accountability of media during transport includes, for example, restricting transport activities to authorized personnel, and tracking and/or obtaining explicit records of transport activities as the media moves through the transportation system to prevent and detect loss, destruction, or tampering. Organizations establish documentation requirements for activities associated with the transport of information system media in accordance with organizational assessments of risk to include the flexibility to define different record-keeping methods for the different types of media transport as part of an overall system of transport-related records.
Configuring Ingress 

Learn how you can configure your Ingress setup to meet your workload needs.



 Preserving the source IP address 

To preserve source IP addresses, you can enable the PROXY protocol for VPC clusters. This option is available for clusters that run version 4.13 or later.

The PROXY protocol provides a convenient way to transport connection information, such as a client's address, across multiple layers of NAT or TCP proxies. For more information on the PROXY protocol, see the [HAProxy specification](https://www.haproxy.org/download/1.8/doc/proxy-protocol.txt).

By default, the Ingress controller receives connections that contain only the source address associated with the load balancer. You can enable the PROXY protocol in VPC clusters to configure the load balancer to preserve the original client address for connections that the Ingress controller receives.



 Enabling the PROXY protocol 



1. Edit the Ingress Controller resource.

oc -n openshift-ingress-operator edit ingresscontroller/default
2. In the Ingress controller resource, find the spec.endpointPublishingStrategy.loadBalancer section and define the following providerParameters values.

endpointPublishingStrategy:
loadBalancer:
providerParameters:
type: IBM
ibm:
protocol: PROXY
scope: External
type: LoadBalancerService
3. Save and apply the resource.







 Disabling PROXY protocol 



1. Edit the Ingress Controller resource.

oc -n openshift-ingress-operator edit ingresscontroller/default
2. In the Ingress controller resource, find the spec.endpointPublishingStrategy.loadBalancer section and define the following providerParameters values.

endpointPublishingStrategy:
loadBalancer:
providerParameters:
type: IBM
ibm:
protocol: TCP
scope: External
type: LoadBalancerService
3. Save and apply the resource.
For more information, see [Change the MAC address of NSX-T Virtual Distributed Router](https://docs.vmware.com/en/VMware-NSX-T-Data-Center/3.1/migration/GUID-538774C2-DE66-4F24-B9B7-537CA2FA87E9.html).

The management NIC on the NSX-T Edge node VM must be able to reach the NSX-T Managers. The tunnel NIC (TEP) must have connectivity to the other NSX-T transport nodes, while the third NIC is connected directly to the NSX-V logical switch (virtual wire) to be bridged.





 Related links 



* [Overview of Edge Bridging in NSX-T](https://docs.vmware.com/en/VMware-NSX-T-Data-Center/3.2/migration/GUID-12FE83E9-2FA9-40F7-A3FF-BC21E13F6720.html)
* [Extending Layer 2 Networks with NSX-T Edge Bridge](https://docs.vmware.com/en/VMware-NSX-T-Data-Center/3.2/migration/GUID-5B9390FB-7E52-4669-AF63-3C3490841432.html)
* [Ordering services for vCenter Server instances](https://cloud.ibm.com/docs/vmwaresolutions?topic=vmwaresolutions-vc_addingservices)
The default value is 600.





 Example 

ibmcloud ce jobrun submit --name myjobrun --image icr.io/codeengine/firstjob --array-indices 1-5





 Example output 

Submitting job run 'myjobrun'...
Run 'ibmcloud ce jobrun get -n myjobrun' to check the job run status.
OK









 Project commands 

Use project commands to create, list, delete, and select a project as the current context.

A project is a grouping of Code Engine entities such as applications, jobs, and builds. A project is based on a Kubernetes namespace. The name of your project must be unique within your IBM Cloud® resource group, user account, and region. Projects are used to manage resources and provide access to its entities.

A project provides the following items.



* Provides a unique namespace for entity names.
* Manages access to project resources (inbound access).
* Manages access to backing services, registries, and repositories (outbound access).
* Has an automatically generated certificate for Transport Layer Service (TLS).



For more information about working with projects, see [Managing projects](https://cloud.ibm.com/docs/codeengine?topic=codeengine-manage-project).

You can use either project or proj in your project commands. To see CLI help for the project commands, run ibmcloud ce proj -h.



 ibmcloud ce project create 

Create a project.

ibmcloud ce project create --name PROJECT_NAME [--endpoint ENDPOINT] [--no-select] [--no-wait] [--output OUTPUT] [--quiet] [--tag TAG] [--wait] [--wait-timeout WAIT_TIMEOUT]



 Command Options 

-n, --name
: The name of the project. Use a name that is unique to your region. The name must be 128 characters or fewer and can contain:



* Any Unicode or alphanumeric character.
* Only these special characters: spaces ( ), periods (.)
: Next, your on-premises client that runs on the location hosts can use [Satellite Link](https://cloud.ibm.com/docs/satellite?topic=satellite-link-cloud-createlink-location) as Layer 4 application transport between the location and other services that run in IBM Cloud or your own applications that run within IBM Cloud. You can use Satellite Link to create location endpoints, which allow resources in IBM Cloud to securely access a resource in your on-premises Satellite location, and cloud endpoints, which allow resources in your on-premises Satellite location to access a resource that runs anywhere outside of the Satellite location. To allow access to a resource, authorization must granted in the Link endpoint's access control list.

When you evaluate whether the minimal Satellite location deployment is the best solution for your environment, keep the following considerations in mind.



* Location endpoints, or endpoints that expose resources that run in your Satellite location, are accessible only from within the IBM Cloud private network or from resources that are connected to the IBM Cloud private network.
* Although you can create endpoints for publicly accessible resources, the endpoints that are created are not publicly accessible, and can only be resolved by the Satellite Link components in IBM Cloud (the Link tunnel server) or in your location (the Link connector).
* For more information about Satellite Link, including an architectural overview and FAQs, review [Understanding Link endpoints and Satellite](https://cloud.ibm.com/docs/satellite?topic=satellite-link-location-cloud).







 Setting up a secure connection to IBM Cloud with Satellite 

The following example setup walks you through creating a minimal Satellite location setup with on-premises hosts, and securely connecting resources that you deploy in this Satellite location to IBM Cloud.



 Step 1: Deploy Satellite to your on-premises environment 

As system administrator, you set up a Satellite location in your on-premises environment to run any applications that require access to IBM Cloud.



1. [Create a Satellite location](https://cloud.ibm.com/docs/satellite?topic=satellite-locations) in your on-premises infrastructure.
2.
Also, you must create a new edge cluster for your Tier-0 and Tier-1 gateways in the second IBM Cloud data center hosts.
5. In the second IBM Cloud data center, access to private network is provided though private uplinks, which are attached to a portable subnet on a private primary VLAN on the IBM Cloud private network. If you provision your instance with public interfaces, access to public network is provided though public uplinks, which are attached to a portable subnet on a public VLAN on the IBM Cloud public network. The uplinks have specific IP addresses to this data center and they cannot move between the data centers.
6. You must deploy two or more edge cluster transport nodes in the regional edge cluster manually. Consider at least one in each zone or data center for high availability. Then, create a new edge cluster by using these edge transport nodes, and create your regional Tier-0 in this cluster. You can select which data center (or edge node) is your preferred Tier-0 path in the regional cluster.
7. Create an overlay transit and create uplinks in Tier-0 gateways into the transit segment. Establish dynamic routing between the Tier-0 gateways. BGP is the preferred routing protocol.
8. Create your Tier-1 gateways in the regional edge cluster. You can select which data center (or edge node) is your preferred Tier-1 path in the regional cluster.
9. You can attach your segments into this level of Tier-1 gateways. You can create multiple segments and advertise them through Tier-1 gateway to north bound Tier-0 gateways.



This network topology example doesn't consider the management and control plane (vCenter and NSX Managers). The control plane high availability is discussed in another availability pattern.

The main reason that you need two layers is for physical north-south connectivity in the data centers. Each data center must have their own private and public VLANs and IP addresses for the uplinks. These IP addresses cannot move between the data centers. Therefore, it requires your attention for routing and network address translation if you use public connectivity in this topology.





 Multisite – multitenant
For more information, see [Create Transport Zones](https://docs.vmware.com/en/VMware-NSX-T-Data-Center/3.1/installation/GUID-F739DC79-4358-49F4-9C58-812475F33A66.htmlGUID-F739DC79-4358-49F4-9C58-812475F33A66).



Refer to [VMware Solution Architectures for IBM Cloud VPC](https://cloud.ibm.com/docs/vmwaresolutions?topic=vmwaresolutions-vpc-ryo-nsx-t) for naming and architectural considerations.

You can order NSX licenses through [IBM Cloud Classic portal](https://cloud.ibm.com/classic/devices/vmwarelicenses).

If you do not have access to VMware customer connect, please contact IBM Cloud Support to download NSX-T images.





 Step 3: Create uplink profile 

In preparation for the next step, you will need to create a new uplink profile



1. Create an uplink profile, assigning the TEP vlan id e.g. 400 and assign the active uplink as uplink-1. For more information, see [Create an Uplink Profile](https://docs.vmware.com/en/VMware-NSX-T-Data-Center/3.1/installation/GUID-50FDFDFB-F660-4269-9503-39AE2BBA95B4.html)







 Step 4: Add host transport nodes 

An NSX Edge Node is a transport node that runs the local control plane daemons and forwarding engines implementing the NSX-T data plane. It runs an instance of the NSX-T virtual switch called the NSX Virtual Distributed Switch, or N-VDS. The Edge Nodes are service appliances dedicated to running centralized network services that cannot be distributed to the hypervisors. An NSX Edge can belong to one overlay transport zone and multiple VLAN transport zones.
SSL offloading requires you to provide an SSL certificate for the application load balancer to perform SSL offloading tasks. You can manage the SSL certificates through the [IBM Cloud Secrets Manager](https://cloud.ibm.com/docs/secrets-manager?topic=secrets-manager-getting-started).

You can create an authorization through [IAM Authorizations](https://cloud.ibm.com/iam/authorizations). Make sure to choose VPC Infrastructure Services as the Source service, select Resources based on selected attributes, and click the Resource type checkbox to expose the dropdown menu. Select Load Balancer for VPC as the resource type from the dropdown. For the Target service, select Secrets Manager. Set the Target service instance access to All instances or to your specific Secrets Manager instance. Assign the Writer service access role. For more information, see [Granting access between services](https://cloud.ibm.com/docs/account?topic=account-serviceauthcreate-auth).

To prevent errors, you must establish the required authorization between your load balancer and IBM Cloud Secrets Manager. In addition, updating certificates in Secrets Manager does not automatically update your ALB. For your load balancer to reflect any changes in the certificate, make a small update (such as changing the health check interval or timeout value) to cause a refresh. This will update the certificate on your load balancer to match the certificate in Secrets Manager. You can then revert any changes you made back to their original values.

Transport Layer Security (TLS) 1.2 and 1.3 are supported. However, TLS 1.3 is used by default unless you specifically configure the client side to utilize 1.2. Application load balancers honor all supported TLS 1.3 ciphers sent by the client-side request.

The following lists the supported ciphers (in order of precedence):



* TLS_AES_256_GCM_SHA384
* TLS_CHACHA20_POLY1305_SHA256
* TLS_AES_128_GCM_SHA256
A listener is the front-end port that the network load balancer is listening on for customer requests. These requests are forwarded to the targets in the pool that is associated with the listener. A pool is a group of targets that are used to distribute the network requests coming into the network load balancer for a specific listener. A member is a back-end server with a specified port that is configured to listen for requests.

Zoom

![Network load balancer work flow](https://cloud.ibm.com/docs-content/v1/content/f02b9c9adcbb7328d95a45e105cec371d50f15eb/vpc/images/nlb-workflow-customer-view.png)

Figure 4. Network load balancer work flow





 Layer 4 load balancing 

Network Load Balancer for VPC provides a layer 4 (known as the transport layer) load-balancing service to the user’s servers in a VPC. It decides where traffic is directed based on the source and destination IP addresses and the port in the packet header. The load balancer does not perform a check on the contents of the packet.

Since layer 4 load balancing requires fewer computations compared to more sophisticated load balancing, such as layer 7, CPU usage and memory are used more efficiently.





 Related links 



* [Network load balancer CLI reference](https://cloud.ibm.com/docs/vpc?topic=vpc-infrastructure-cli-plugin-vpc-referencenlb-anchor)
* [Load balancer API reference](https://cloud.ibm.com/apidocs/vpclist-load-balancer-profiles)
* [NLB for VPC infrastructure resources for Terraform](https://registry.terraform.io/providers/IBM-Cloud/ibm/latest/docs/data-sources/is_lb) (VPC infrastructure > Resources)
* [Network load balancer in IBM Cloud® Kubernetes Service](https://cloud.ibm.com/docs/containers?topic=containers-vpc-lbaasnlb_vpc)