vania-janet/multiturn-rag-retrieval-data huggingface dataset:
ibmcloud iam trusted-profile-rule-create Profile-b2f13064-2b8c-4e4b-9181-c1973a408e3c               --name NewRule4IKS --type Profile-CR --cr-type IKS_SA                --conditions "claim:service_instance,operator:EQUALS,vlaue:c0pigdctkkc07fs7pm06"                --conditions "claim:namespace,operator:EQUALS,value:my-namespace"





 Creating trusted profile conditions for VPC 

To connect the trusted profile with the ID Profile-b2f13064-2b8c-4e4b-9181-c1973a408e3c to all virtual servers in one VPC r206-1db73eed-b0fb-b04f-bb57-4d3a3c2dff9d in the account 444aebb0657c7f0f3aae8e7bdc78709a, specify the following command:

ibmcloud iam trusted-profile-rule-create Profile-b2f13064-2b8c-4e4b-9181-c1973a408e3c               --name NewRule4VSI --type Profile-CR --cr-type VSI                --conditions "claim:vpc_id,operator:EQUALS,value:r206-1db73eed-b0fb-b04f-bb57-4d3a3c2dff9d"









 Conditions in v2 access policies 

Time-based conditions for IAM access policies use /v2/policies syntax. Policies that use /v1/policies syntax aren't eligible to add time-based conditions. For more information, see [Access policy version limitations](https://cloud.ibm.com/docs/account?topic=account-known-issuespolicy-version-limit).
CBR rules do not apply to provisioning or deprovision processes.





 About Network Zones 

By creating network zones, you can create a list of allowed locations where an access request originates. A set of one or more network locations can be specified by IP addresses such as individual addresses, ranges or subnets, and VPC IDs. After you create a network zone, you can add it to a rule.



 Create Network Zones using the CBR API 

The API supports defining [network zones](https://cloud.ibm.com/apidocs/context-based-restrictionsnetwork-zones) by calling on both public ([https://cbr.cloud.ibm.com](https://cbr.cloud.ibm.com)), and private ([https://private.cbr.cloud.ibm.com](https://private.cbr.cloud.ibm.com)), endpoints.

Using the path: "/v1/zones" with the GET method will list the zones. Using POST, you can create a new zone with the appropriate information using the following request body format example as a guide:

{
  "name": "an example of a zone",
  "description": "this is an example of a zone",
  "account_id": "12ab34cd56ef78ab90cd12ef34ab56cd",
  "addresses": [
    {
      "type": "ipAddress",
      "value": "169.23.56.234"
    },
    {
      "type": "ipRange",
      "value": "169.23.22.0-169.23.22.255"
    },
    {
      "type": "subnet",
      "value": "192.0.2.0/24"
    },
    {
      "type": "vpc",
You can enter a single IP address 17.5.7.8, an IP address range 17.5.7.8 - 17.5.9.5, or IP subnets 17.5.7.8.0/16, or a [network zone](https://cloud.ibm.com/docs/account?topic=account-context-restrictions-whatisnetwork-zones-whatis)networkZoneName. Make sure to use IPv4 or IPv6 addresses, and to separate multiple values with a comma. If there is already an IP address restriction that exists, the resource overrides the restriction.
4. Click Save.







 Allowing specific IP addresses for an account by using Terraform 

If you are assigned the following access, you can update the restricted IP addresses for an account:



* An IAM policy with the Editor, Operator, or Administrator role on the IAM identity service.



To restrict all users to using only specific IP addresses, complete the following steps:



1. In your Terraform configuration file, find the Terraform code that you used to create the iam_account_settings_instance.
2. Enter the IP addresses that you want to restrict all users to using. The IP addresses listed are the only ones from which users in the account can log in to IBM Cloud®.

resource "ibm_iam_account_settings" "iam_account_settings_instance" {
allowed_ip_addresses = "17.5.7.8, 17.5.7.8 - 17.5.9.5, 17.5.7.8.0/16"
}
3. Provision the resources from the main.tf file. For more information, see [Provisioning Infrastructure with Terraform](https://www.terraform.io/cli/run).



1. Run terraform plan to generate a Terraform execution plan to preview the proposed actions.

terraform plan
2. Run terraform apply to create the resources that are defined in the plan.

terraform apply
Address: 169.xx.xxx.xxx,169.xx.xxx.xxx
Default backend: default-http-backend:80 (<none>)
Rules:
Host Path Backends
---- ---- --------
mycluster-<hash>-0000.us-south.containers.appdomain.cloud
/tea myservice1:80 (<none>)
/coffee myservice2:80 (<none>)
Annotations:
custom-port: protocol=http port=7490; protocol=https port=4431
location-modifier: modifier='' serviceName=myservice1;modifier='^' serviceName=myservice2
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Warning TLSSecretNotFound 1m router-default-69d6f598f8-vn8tj Failed to apply ingress resource.
Warning AnnotationError 2s router-default-69d6f598f8-vn8tj Failed to apply ingress.bluemix.net/custom-port annotation.
Warning TLSSecretNotFound 1m router-dal10-y2d4359tf4-g4ar7 Failed to apply ingress resource.
Warning AnnotationError 2s router-dal10-y2d4359tf4-g4ar7 Failed to apply ingress.bluemix.net/custom-port annotation.
3. Check the Ingress resource configuration file.

oc get ingress -o yaml



1. Ensure that you define a host in only one Ingress resource. If one host is defined in multiple Ingress resources, the Ingress controller might not forward traffic properly and you might experience errors.
2. Check that the subdomain and TLS certificate are correct.
* ibmcloud is network-acl-rule-update 72b27b5c-f4b0-48bb-b954-5becc7c1dcb3 8daca77a-4980-4d33-8f3e-7038797be8f9 --action allow --direction inbound --protocol tcp --source 10.2.2.2 --dest 10.2.2.3 --source-port-min 555 --source-port-max 666 --destination-port-min 11 --destination-port-max 55
* ibmcloud is network-acl-rule-update 72b27b5c-f4b0-48bb-b954-5becc7c1dcb3 8daca77a-4980-4d33-8f3e-7038797be8f9 --action allow --direction inbound --protocol all --source 10.2.2.2 --dest 10.2.2.3 --before-rule-id 72251a2e-d6c5-42b4-97b0-b5f8e8d1f479
* ibmcloud is network-acl-rule-update 72b27b5c-f4b0-48bb-b954-5becc7c1dcb3 8daca77a-4980-4d33-8f3e-7038797be8f9 --action allow --direction inbound --protocol all --source 10.2.2.2 --dest 10.2.2.3 --output JSON







 Command options 



* ACL: ID or name of the network ACL.
* RULE: ID or name of the rule.
* --vpc: ID or name of the VPC. It is only required to specify the unique resource by name inside this VPC.
* --name: New name of the rule.
* --direction: Direction of traffic to enforce. One of: inbound, outbound.
* --action: One of: allow, deny.
Required Flows:<br><br><br><br> * Outbound TCP 8086 and TCP 8087 from your private <br> VLANs to IP ranges documented in dal09 and dal10 only.<br> * Outbound TCP 2546 from your private VLANs to IP ranges <br> documented for each DC where you need to access your vault.<br><br><br> 
 ams03 10.3.134.0/24 
 che01 10.200.22.0/24 
 dal05 10.1.146.0/24 
 dal08 100.100.6.0/24 
 dal09 10.2.118.0/24 
 dal09 10.2.126.0/24 
 dal10 10.200.86.0/24 
 dal12 10.200.118.0/24 
 dal13 10.200.134.0/24 
 fra02 10.3.86.0/24 <br>10.201.150.0/24 
 fra04 10.201.118.0/24 
 fra05 10.201.134.0/24 
 lon02 10.1.214.0/24 <br>10.201.102.0/24 
 lon04 10.201.38.0/24 
 lon05 10.201.54.0/24 
 lon06 10.201.70.0/24 
 mil01 10.3.150.0/24 
 mon01 10.3.118.0/24 
 osa21 10.202.118.0/24 
 osa22 10.202.150.0/24 
 osa23 10.202.166.0/24 
 par01 10.2.150.0/24 
 sao01 10.200.6.0/24 
 sjc01 10.1.198.0/24 <br>10.200.38.0/24 
 sjc03 10.3.182.0/24 
 sjc04 10.201.86.0/24
A set of one or more network locations can be specified by IP addresses such as individual addresses, ranges or subnets, VPC IDs, and service references. After you create a network zone, you can add it to a rule.

To create a network zone, call the [Context-based restrictions API](https://cloud.ibm.com/apidocs/context-based-restrictionscreate-zone) as shown in the following example:



* Curl
* Java
* Python
* Go
* Node



curl -X POST --location --header "Authorization: Bearer {iam_token}" --header "Accept: application/json" --header "Content-Type: application/json" --data '{ "name": "an example of zone", "description": "this is an example of zone", "account_id": "12ab34cd56ef78ab90cd12ef34ab56cd", "addresses": [ { "type": "ipAddress", "value": "169.23.56.234" }, { "type": "ipRange", "value": "169.23.22.0-169.23.22.255" }, { "type": "subnet", "value": "192.0.2.0/24" }, { "type": "vpc", "value": "crn:v1:bluemix:public:is:us-south:a/12ab34cd56ef78ab90cd12ef34ab56cd::vpc:r134-d98a1702-b39a-449a-86d4-ef8dbacf281e" }, { "type": "serviceRef", "ref": { "account_id": "12ab34cd56ef78ab90cd12ef34ab56cd", "service_name": "cloud-object-storage" } } ], "excluded": [ { "type": "ipAddress", "value": "169.23.22.127" } ] }' "{base_url}/v1/zones"
./apply.sh firewall_tf
2. Run the test suite.

Your expected results are: Connectivity within a VPC, enterprise -> transit, enterprise <-> spoke same zone pass. But all transit -> spoke, all transit -> enterprise and enterprise <--> spoke cross zone fail due to asymmetric routing issues.

pytest -m "curl and lz1 and (rz1 or rz2)"

[Part two](https://cloud.ibm.com/docs/solution-tutorials?topic=solution-tutorials-vpc-transit2) of this tutorial will route all VPC <-> different VPC traffic through the router and resolve these issues. But first it is important to learn what is happening.







 Ingress Routing 

Traffic reaches the firewall-router appliance through routing tables.



1. Visit the [VPCs](https://cloud.ibm.com/vpc-ext/network/vpcs) in the IBM Cloud console.
2. Select the transit VPC.
3. Click on Manage routing tables.
4. Click on the tgw-ingress routing table.



The zone is determined by the Transit Gateway which will examine the destination IP address of each packet and route it to the matching zone based on VPC Address Prefixes discussed in the next section.

Notice how wide the routes are in the transit's ingress routing table (shown for Dallas/us-south):



 Zone Destination Next hop 

 Dallas 1 0.0.0.0/0 10.1.0.196 
 Dallas 2 0.0.0.0/0 10.2.0.196 
 Dallas 3 0.0.0.0/0 10.3.0.196 



The next_hop identifies the firewall-router. In the table above 10.1.0.196 zone Dallas 1 and 10.2.0.196 zone Dallas 2, etc. You can observe this using the IBM Cloud console.



1.
The CLI accepts the values enabled (default), disabled, and report. For more informaiton about enforcement, see [Rule enforcement](https://cloud.ibm.com/docs/account?topic=account-context-restrictions-whatisrule-enforcement).

--file (string)
: The supplied file is used to create the rule. This flag is unique and cannot be used with other flags. The file needs to follow the JSON schema for the rule create API. For more information, see the [Context-based restrictions API](https://cloud.ibm.com/apidocs/context-based-restrictionscreate-rule-request).







 ibmcloud cbr rules 

This operation lists rules in the specified account.

ibmcloud cbr rules [--enforcement-mode ENFORCEMENT-MODE] [--region REGION] [--resource RESOURCE] [--resource-type RESOURCE-TYPE] [--service-instance SERVICE-INSTANCE-GUID] [--service-name SERVICE-NAME] [--zone-id ZONE-ID] [--sort SORT]



 Example 

ibmcloud cbr rules





 Command options 

--enforcement-mode (string)
: How the rule is enforced. The CLI accepts the values enabled (default), disabled, and report. For more informaiton about enforcement, see [Rule enforcement](https://cloud.ibm.com/docs/account?topic=account-context-restrictions-whatisrule-enforcement).

--region (string)
: The region resource attribute.

--resource (string)
: The resource resource attribute.

--resource-type (string)
: The resourceType resource attribute.

--service-instance SERVICE_INSTANCE_GUID (string)
: GUID of the service instance. This option is exclusive with the --file option.

--service-name (string)
: The serviceName resource attribute.

--zone-id (string)
: The globally unique ID of the zone.

--sort (string)
: Sorts results by using a valid sort field.
Note that the service_name for IBM Cloud Kubernetes Service is containers-kubernetes. To find a list of service names, run the ibmcloud cbr service-ref-targets command. To find a list of API types for a service, run the ibmcloud cbr api-types --service-name SERVICE command.



Example command to create a rule that uses the addresses key and the cluster API type and the ipAddress type.

ibmcloud cbr rule-create my-rule-1 --service-name containers-kubernetes --api-type crn:v1:bluemix:public:containers-kubernetes::::api-type:cluster --zone-id ZONE-ID

The following command creates a rule that protects the CLUSTER-ID cluster. Only resources in the NETWORK-ZONE-ID network zone can access the cluster. This rule includes both the cluster and management API types.

ibmcloud cbr rule-create my-rule-2 --service-name containers-kubernetes --service-instance CLUSTER-ID --zone-id NETWORK-ZONE-ID

The following example command creates a rule that allows all private network connections, but allows only resources in the allow-client-ip network zone to connect to the cluster over the public network. For more information about this scenario, see [Setting up context-based restrictions](https://cloud.ibm.com/docs/containers?topic=containers-cbr-tutorial).

ibmcloud cbr rule-create --api-types crn:v1:bluemix:public:containers-kubernetes::::api-type:cluster --description "privateAccess=allowAll, publicAccess=oneIP" --service-name containers-kubernetes --service-instance CLUSTER-ID --context-attributes endpointType=private --context-attributes endpointType=public,networkZoneId=allow-client-ip





 Creating rules from the console 



1. [Review the available contexts](https://cloud.ibm.com/docs/containers?topic=containers-cbrcbr-overview) and determine the rules you want to create.
You may see this message attempting to attach a public gateway in zone-1 to a subnet in zone-2.





 ipsec_policies_quota_exceeded 

Message: The IPsec policy cannot be created because your account has reached the quota.

The quotas per resource are specified on the [Quotas](https://cloud.ibm.com/docs/vpc-on-classic?topic=vpc-on-classic-quotasvpn-quotas) page.

To view current IPsec policies, use the GET /ipsec_policies API. Equivalent CLI command: ibmcloud is ipsec-policies





 ipsec_policy_duplicate_name 

Message: The name <ipsec_policy_name> is in use already by IPsec policy <ipsec_policy_id>.

Provide a different IPsec policy name. Try again in a few minutes. If this problem persists, [contact support](https://cloud.ibm.com/docs/vpc-on-classic?topic=vpc-on-classic-getting-help-and-support).





 ipsec_policy_in_use 

Message: The IPsec policy <ipsec_policy_id> is in use by one or more connections.

An IPsec policy cannot be deleted if it is in use by one or more connections.

To see which connections are using the IPsec policy, use the GET /ipsec_policies/<ipsec_policy_id>/connections API. Equivalent CLI command: ibmcloud is ipsec-policy-connections IPSEC_POLICY_ID





 ipsec_policy_invalid_name 

Message: The name <ipsec_policy_name> is not a valid IPsec policy name.

A valid IPsec policy name starts with a letter, followed by letters, digits, underscores or hyphens.





 ipsec_policy_not_created 

Message: The IPsec policy <ipsec_policy_id> could not be created.

Try again in a few minutes.
A context restriction matched in reporting mode

As discussed, in report mode, all matching requests generate a log entry. In the event details you see an attribute decision with a value of either Permit or Deny. In the screenshot above it is Deny.
5. Back in the browser tab with the shell, list the container images in the namespace.

ibmcloud cr images --restrict $YOUR_INITIALS-e2esec
6. In a third browser tab, navigate to the [CBR rules](https://cloud.ibm.com/context-based-restrictions/rules). Next to the registry-related rule you created earlier, click on the dot menu and select Edit. Go to Describe your rule (Step 3) and switch the rule from Report-only to Enabled. Activate the change by pressing the Apply button.
7. Go back to the browser tab with IBM Cloud Shell. Issue the same command as before to list the images:

ibmcloud cr images --restrict $YOUR_INITIALS-e2esec

This time, it should result in an error message that you are not authorized.
8. In the browser tab with the logs, you should find a new record similar to the following:

Zoom

![Verify rules in enforced mode](https://cloud.ibm.com/docs-content/v1/content/f84e2238288b7f0355715a4c355609ce7ac48fb0/solution-tutorials/images/solution67-cbr-enhanced-security/CBR_rule_denied_registry.png)

A context restriction rendered a deny

The rule has been enforced and, based on how you tried to access the registry, the access has been denied. The reason is that rule allows access from a specific VPC only. The Cloud Shell environment and its IP address, as documented in the logs in the requestData->environment fields, differ. Therefore, the request is denied.



When working with the Activity Tracker logs, you can utilize query strings like the following to easily find the relevant log records:
* --output value specifies the output format. Currently, json is the only supported format.







 Listing a permitted network using the API 

To list all linked zones using the API, follow these steps:



1. Set up your API environment with the correct variables.
2. Store the following values in variables to be used in the API command:



* INSTANCE_ID, which is the unique identifier of a service instance.
* LINKED_DNSZONE_ID which is the unique identifier of a linked zone.
* IAM_TOKEN, which is the IAM authorization token.



3. When all variables are initiated, list the linked zones:

curl -X GET https://api.dns-svcs.cloud.ibm.com/v1/instances/$INSTANCE_ID/linked_dnszones/$LINKED_DNSZONE_ID/permitted_networks -H "Authorization: $IAM_TOKEN"







 Getting the details of a permitted network using the API 

To get the details of a permitted network using the API, follow these steps:



1. Set up your API environment with the correct variables.
2. Store the following values in variables to be used in the API command:



* INSTANCE_ID, which is the unique identifier of a service instance.
* LINKED_DNSZONE_ID which is the unique identifier of a linked zone.
* PERMITTED_NETWORK_ID which is the unique identifier of a permitted network
* IAM_TOKEN, which is the IAM authorization token.



3. When all variables are initiated, get the details of the permitted network:

curl -X GET https://api.dns-svcs.cloud.ibm.com/v1/instances/$INSTANCE_ID/linked_dnszones/$LINKED_DNSZONE_ID/permitted_networks/$PERMITTED_NETWORK_ID -H "Authorization: $IAM_TOKEN"
policies {
from-zone SL-PRIVATE to-zone SL-PRIVATE {
policy Allow_Management {
match {
source-address any;
destination-address [ SL_PRIV_MGMT SERVICE ];
application any;
}
then {
permit;
}
}
}
from-zone SL-PUBLIC to-zone SL-PUBLIC {
policy Allow_Management {
match {
source-address any;
destination-address SL_PUB_MGMT;
application [ junos-ssh junos-https junos-http junos-icmp-ping ];
}
then {
permit;
}
}
}
}
zones {
security-zone SL-PRIVATE {
interfaces {
ge-0/0/0.0 {
host-inbound-traffic {
system-services {
all;
}
}
}
}
}
security-zone SL-PUBLIC {
interfaces {
ge-0/0/1.0 {
host-inbound-traffic {
system-services {
all;
}
}
}
}
}
}
}
interfaces {
ge-0/0/0 {
description PRIVATE_VLANs;
flexible-vlan-tagging;
native-vlan-id 1214;
unit 0 {
vlan-id 1214;
family inet {
address 10.129.33.87/26;
}
}
}
ge-0/0/1 {
description PUBLIC_VLAN;
flexible-vlan-tagging;
native-vlan-id 764;
unit 0 {
vlan-id 764;
family inet {
address 161.202.136.77/29;
}
family inet6 {
address 2401:c900:1001:0210:0000:0000:0000:000a/64;
}
}
}
* Subnet ID: "7ec86020-1c6e-4889-b3f0-a15f2e50f87e"



* A secondary VLAN interface with ID "4". This VLAN interface is floatable.
* Profile name: "bx2d-metal-192x768"
* Zone: "us-south-1"



The API request is similar to:

curl -X POST "$vpc_api_endpoint/v1/bare_metal_servers?version=2021-03-09&generation=2" -H "Authorization: $iam_token" -d '{
"initialization": {
"image": {
"id": "r134-31c8ca90-2623-48d7-8cf7-737be6fc4c3e"
},
"keys": [
{"id": "a6b1a881-2ce8-41a3-80fc-36316a73f803"}
]
},
"primary_network_interface": {
"interface_type": "pci",
"name": "my-primary-network-interface",
"subnet": {
"id": "7ec86020-1c6e-4889-b3f0-a15f2e50f87e"
},
"allowed_vlans": [4]
},
"network_interfaces":[
{
"interface_type": "vlan",
"name": "my-vlan-interface",
"allow_interface_to_float": true,
"subnet": {
"id": "2302-6d5fe694-12f7-4161-b979-21bb4e872696"
},
"vlan": 4
}
],
"name": "my-bare-metal-server",
VPN gateway limitations 

Lists known limitations for IBM Cloud VPN for VPC.



* A VPN gateway for VPC accepts VPN packets with [UDP Encapsulation of IPsec ESP Packets](https://tools.ietf.org/html/rfc3948) only. The [Encapsulating Security Payload (ESP)](https://tools.ietf.org/html/rfc4303) is not accepted. Make sure that the NAT-T feature is enabled on your on-premises VPN device. Also, make sure that UDP ports 500 and 4500 are allowed for both IBM VPC NACL and peer networks.
* When multiple networks, subnets, or both are associated with either an IBM Cloud VPN gateway or an on-premises device, avoid mixing policy-based and route-based VPNs. Policy-based VPNs create a tunnel for each target network range. However, route-based VPNs route everything to a peer device through a single tunnel. Therefore, when multiple network ranges are configured, only a single tunnel that is associated with a single-network range can be established. Combining contiguous subnets into a single superset CIDR is a valid workaround to this limitation.
* Peer subnets of a VPN gateway connection cannot overlap.
* When connecting a policy-based VPN with a route-based peer (or static, route-based VPN with a policy-based peer), use only a single network range for both sides. A policy-based VPN uses one tunnel for each associated network. However, a route-based VPN requires only a single tunnel. Therefore, a connection between different types of VPNs associated with multiple network ranges on either side might result in a connection that only works for a single-network range.

Zoom

![Mixed VPN Types use case](https://cloud.ibm.com/docs-content/v1/content/f02b9c9adcbb7328d95a45e105cec371d50f15eb/vpc/images/vpn-mixed-types.png)

Figure 2. Mixed VPN Types use case
Create a Profile-SAML rule with rule name my-rule, realm name set to https://w3id.sso.ibm.com/auth/sps/samlidp2/saml20, expiration set to 1200 seconds for trusted profile my-profile with the rule conditions: cn EQUALS my_user

ibmcloud iam trusted-profile-rule-create my-profile --name my-rule --type Profile-SAML --conditions claim:cn,operator:EQUALS,value:my_user --realm-name https://w3id.sso.ibm.com/auth/sps/samlidp2/saml20 --expiration 1200

Create a Profile-SAML rule with realm name set to https://w3id.sso.ibm.com/auth/sps/samlidp2/saml20 and expiration set to 1200 seconds for trusted profile my-profile with the rule conditions: cn EQUALS my_user and blueGroups NOT_EQUALS jaas_master

ibmcloud iam trusted-profile-rule-create my-profile --type Profile-SAML --conditions claim:cn,operator:EQUALS,value:my_user --conditions claim:blueGroups,operator:NOT_EQUALS,value:jaas_master --realm-name https://w3id.sso.ibm.com/auth/sps/samlidp2/saml20 --expiration 1200

Create a Profile-CR rule with rule name my-rule, compute resource type IKS_SA, and with the rule conditions: namespace EQUALS default and crn EQUALS crn:test:bluemix:public:containers-kubernetes:us-south:a/test::

ibmcloud iam trusted-profile-rule-create my-profile --name my-rule --type Profile-CR --conditions claim:namespace,operator:EQUALS,value:default --conditions claim:crn,operator:EQUALS,value:crn:test:bluemix:public:containers-kubernetes:us-south:a/test:: --cr-type IKS_SA







 ibmcloud iam trusted-profile-rules