vania-janet/multiturn-rag-retrieval-data huggingface dataset:
* If protocol is either tcp or udp, then the rule can also contain the port range (PortMin, PortMax). You must set either both ports, or neither. When neither is set, then traffic is allowed on all ports. For a single port, you must set both ports to the same value.
* When protocol is icmp, you can optionally specify the type property. If specified, then ICMP traffic is allowed for only the specified ICMP type. Further, if you specify type, you can optionally specify the code property to allow traffic for only the specified ICMP code.



* Remote - Describes the set of network interfaces to which this rule allows traffic (or from which, for outbound rules). You can specify this value as either an IP address, a CIDR block, or all the identifiers of a single security group (ID, CRN, and name). If this value is omitted, a CIDR block of 0.0.0.0/0 is used to allow traffic from any source (or to any source, for outbound rules).



For more information on setting up security group rules using the CLI, see the [Command list cheat sheet](https://cloud.ibm.com/docs/vpc?topic=vpc-configuring-the-security-group&interface=clicommand-list-cheat-sheet). For more information on setting up security group rules using the API, see [Setting up the security group for your virtual server instance by using the API](https://cloud.ibm.com/docs/vpc?topic=vpc-configuring-the-security-group&interface=apisg-using-api).





 Getting started 

To get started using security groups, follow these steps:



1. Decide if you want to create a new security group for your resource, and [Create your security group](https://cloud.ibm.com/docs/vpc?topic=vpc-configuring-the-security-group&interface=ui).
2.
<br><br> * Isolate management VPC and allow only a limited number of network connections<br> * All other connections from or to management VPC are forbidden<br><br><br> ACL and security group rules in management VPC Isolate environment for access through site-to-site VPN<br><br><br><br> * All ports to other VPCs are open<br><br><br> More ports might be opened in preset or added manually after deployment 
 <br><br> * Isolate workload VPC and allow only a limited number of network connections<br> * All other connections from or to workload VPC are forbidden<br><br><br> ACL and security group rules in workload VPC All ports to other VPCs are open More ports might be opened in preset or added manually after deployment 
 Load VPN configuration to simplify VPN setup VPNs VPN configuration is the responsibility of the customer 
 Collect and store Internet Protocol (IP) traffic information with Activity Tracker and Flow Logs Activity Tracker 
 Securely connect to multiple networks with a site-to-site virtual private network 







 Key and password management architecture decisions 



Table 3. Key and password management architecture decisions

 Requirement Component Reasons for choice Alternative choice 

 <br><br> * Use public SSH key to access virtual server instances by using SSH<br><br><br> Public SSH key provided by customer Ask customer to specify the key. Accept the input as secure parameter. 









 Next steps 

Read about [IBM Cloud for Financial Services](https://cloud.ibm.com/docs/framework-financial-services?topic=framework-financial-services-about)
* Allow HTTP traffic to the internet.
* Allow all outbound traffic to the subnet 10.10.20.0/24.
* Deny all other outbound traffic.





Table 2. Information for configuring outbound rules.

 Priority Allow/Deny Protocol Source Destination 

 1 Allow TCP Any IP, any port Any IP, ports 80 - 80 
 2 Allow ALL Any IP, any port 10.10.20.0/24, any port 
 3 Deny ALL Any IP, any port Any IP, any port
Configuring ACLs and security groups for use with endpoint gateways 

You can configure access control lists (ACLs) and security groups for use with endpoint gateways.



 Configuring ACLs for use with endpoint gateways 

You can use ACLs to control the traffic in your Virtual Private Endpoint (VPE) for VPC deployment. Use ACLs to filter traffic going to and from the VPE.

Ideally, you should configure the ACLs before taking an action on a virtual private endpoint, such as creating or updating. For instructions, see [Setting up network ACLs](https://cloud.ibm.com/docs/vpc?topic=vpc-using-aclsusing-acls).

The ACL is on the subnet that holds the reserved IP, which is bound to the endpoint gateway that creates the VPE. You require the same rule on each subnet that has an endpoint connected to the VPE. For example, suppose that you have three reserved IPs (one IP in each zone) connected to the endpoint gateway. You can:



* Use the same ACL on each of the three subnets.



OR



* If you have different ACLs on the three different subnets, make sure to set up a rule on each of ACLs for the same VPE.







 Attaching security groups to endpoint gateways 

Attach security groups to endpoint gateways to improve the security of their applications. You can then manage these security groups and tighten their security rules for inbound traffic towards your endpoint gateways.

You can attach security groups when creating an endpoint gateway. After the endpoint gateway is created, you can modify the security groups attached to the endpoint gateway (for example, apply security group rules to an endpoint gateway's data paths).

Note the following:



* When you create an endpoint gateway without specifying a security group, the VPC default security group is attached to the endpoint gateway.
* You can specify a maximum of five security groups when creating an endpoint gateway.
* To attach an existing security group to an endpoint gateway, add the endpoint gateway to the security group's array of targets.
Context-based restrictions check that an access request comes from an allowed context that you configure. Also, the rules might not take effect immediately due to synchronization and resource availability.

After you create rules, you can [update](https://cloud.ibm.com/apidocs/context-based-restrictionsreplace-rule) and [delete](https://cloud.ibm.com/apidocs/context-based-restrictionsdelete-rule) them.







 Next steps 

You must follow the creation or modification of zones or rules with adequate testing to ensure access and availability.

Users who attempt to access your resources outside of the defined zones receive HTTP error 403 when the appropriate rules are not established.
Monitoring context-based restrictions 

Context-based restrictions protect your resources by denying access to identities that don't satisfy context requirements, such as making access requests from the network zones and endpoint types that you define. You can enable context-based restrictions upon creation, or choose to set the rule to report-only mode. Use Activity Tracker to monitor enabled rules, and report-only rules to view how the rule affects your users, applications, and workflows without enforcing the rule.



 Before you begin 

You must create an instance of the Activity Tracker service in the Frankfurt (eu-de) region to monitor events for context-based restrictions. For more information, see [Provisioning an instance](https://cloud.ibm.com/docs/activity-tracker?topic=activity-tracker-provision).





 Determining how rules would affect access by using report-only mode 

It can be difficult to predict exactly how your rules might affect users, applications, and workflows. At first, you might create rules that are too stringent and break your workflows. Or, they are too accessible and might allow more users than you intend to access your resources. The recommendation is to first set your rule to report-only mode for at least 30 days before you enable it so that you can monitor the rule's impact.

Complete the following steps to view how rules affect your users' and applications' access in report-only mode by using Activity Tracker:



1. In the IBM Cloud console, go to the Navigation menu icon ![Navigation Menu icon](https://cloud.ibm.com/docs-content/v1/content/4d8c6eec891cff72b666dc24bd3211810c77fb42/icons/icon_hamburger.svg) > Observability > Activity Tracker.
2. Click Open dashboard on the dashboard that you use to monitor context-based restrictions.
3. Use the search field to narrow the results to report-only context-based restrictions events.



1. To view potentially blocked access requests, search for action:context-based-restrictions.policy.eval responseData.isEnforced:==false responseData.decision:Deny.
You can also skip APIs to restrict all operations on the service that you select.







 Contexts 

Contexts define where your resource can be accessed. A context is made up of the allowed endpoint types and network zones that you configure.



* If a context includes network zones, then access is granted only when the request is created from within one of those zones.
* If a context includes service endpoint types, then access is granted only when the request is received over a connection that matches one of those types.
* If a context includes multiple restrictions, for example, both zones and endpoint types, then all restrictions must be satisfied for access to be granted.





 Network zone 

A network zone represents an allowlist of IP addresses where an access request is created. It defines a set of one or more network locations that are specified by the following attributes:



* IP addresses, which include individual addresses, ranges, or subnets.
* VPCs
* Service references, which allow access from other IBM Cloud® services.





 IP addresses 

Customers can specify the IP addresses they know that they want to be able to send traffic from. Anything outside of the specified IP addresses is denied.





 VPCs 

If you have apps that are deployed in a VPC that need access to a context-based restricted resource, you can include the VPC IP addresses in your network zone. To do so, select the target VPC in your network zone and add that network zone to your rule. This way, you don’t have to find the IP addresses that the VPC uses. Resources that are contacted see that the request is coming from a set of allowed IP addresses.





 Service references 

A service reference represents the network locations of a service or service instance. Including a service reference in a network zone adds the IP addresses associated with the service to your allowlist without requiring you to know the service's underlying IP addresses. Service references are helpful since the network locations of cloud services are unknown to the context-based restriction administrator and can change over time.

The following is a list of services that you can add to a network zone as a service reference:



Table 1. Services that are compatible with service references.

 Service Service type 

 All Account Management services Account Management
For more information about this scenario, see [Setting up context-based restrictions](https://cloud.ibm.com/docs/containers?topic=containers-cbr-tutorial).

ibmcloud cbr zone-create --addresses 129.41.86.7 --description "Allow only client IP" --name allow-client-ip







 Creating network zones from the console 



1. Determine the resources that you want add to your allowlist.
2. Follow the steps to [create context-based restrictions in the console](https://cloud.ibm.com/docs/account?topic=account-context-restrictions-create). Add the Kubernetes service to your network zones to allow IBM Cloud Kubernetes Service to access services and resources in your account.









 Creating rules 

Define rules to protect access to resources in your account. The contexts that you define in your rules determine how the resources in your network zones (allowlists) can interact with the resources defined in the rule.

Review the [limitations](https://cloud.ibm.com/docs/containers?topic=containers-cbr&interface=uicbr-limitations) before you create rules.



 Creating rules by using the API 

Review the following example requests to create rules. For more information about the v1/rules API, see the [API docs](https://cloud.ibm.com/apidocs/context-based-restrictionscreate-rule).

After you create a rule, it might take up to 10 minutes to before you can update that rule due to IAM TTL response caching.

The following example payload creates a rule that protects the CLUSTER-ID cluster. Only resources in the NETWORK-ZONE-ID zone can access the cluster. Since no operations are specified, resources in the NETWORK-ZONE-ID zone can access both the cluster and management APIs.

{
"description": "Example rule 1",
"resources": [
{
"attributes":
{
"name": "accountId",
"value": "ACCOUNT-ID"
},
{
"name": "serviceName",
The IAM system doesn't have to evaluate permit and deny policies to determine what actions are allowed, instead the system just evaluates what resources you have policies for and what level of access is allowed by your assigned roles.

To reduce the number of policies in the account and keep only the minimum access that is required for each user, you can identify and remove the infrequently used access policies. For more information, see [Managing inactive policies](https://cloud.ibm.com/docs/account?topic=account-iam-audit-policiesiam-audit-policies-list).

When you specify a resource in a policy because IBM Cloud is [attribute-based](https://cloud.ibm.com/docs/account?topic=account-access-management-overviewaccess-management-system), you can specify a broad set of resources for a user to have access to, for example all resources in a resource group. Or, you can narrow the user's access to a specific instance of a single service or even a subresource type, such as a Object Storage bucket. IBM Cloud IAM provides a high level of flexibility and granularity to help you assign only the type of access that is required. A few examples of the different levels of access that you can assign by using attributes in an access policy are the following:



* All Account Management services
* A specific account management service
* All Identity and Access Enabled services within the account, which includes all catalog services that use IAM for access management
* All resources that belong to a resource group
* All resource types of a single service across the entire account, regardless of resource group assignment
* A specific instance of a service in the account
* A single subresource type within an instance, for example, a bucket in an Object Storage instance



If a specific predefined platform or service role doesn't fit what you're looking for when assigning the level of access, you can create a [custom role](https://cloud.ibm.com/docs/account?topic=account-custom-roles) for a specific service and then choose from the available actions to create a role that fits your organization's needs.



 Policy example
[CHANGE LOG](https://cloud.ibm.com/docs/cloud-infrastructure?topic=cloud-infrastructure-ibm-cloud-ip-rangescloud-infrastructure-jul2522)

To provision and reload classic Virtual Servers and classic Bare Metal Servers, the following private service networks must be allowed through your gateway appliances and firewalls.

Be sure to configure rules and verify routes for the service networks listed in the table below for dal10, wdc04, and the location of your server.

Additionally, complete the following steps:



* Allow and route the following service networks to the BCR on your gateway appliance or firewall for all Bare Metal and Virtual Server provisions and reloads: 10.0.64.0/19, 10.200.80.0/20, 161.26.13.0/24, 161.26.96.0/22, 166.9.12.0/23, 166.9.48.0/24, 166.9.50.0/24, 166.9.228.0/24, 166.9.250.192/27, 10.3.160.0/20, 10.201.0.0/20, 161.26.92.0/22, 161.26.132.0/22, 166.9.20.0/23, 166.9.231.0/24.
* For RHEL servers, ensure the entire 161.26.0.0/16 is allowed and routed properly to the BCR. Add any additional datacenter service networks that are mentioned in the RHEL section near the bottom of the page.
* Allow traffic between the service networks and your server in both directions.
* By default, all classic servers and classic gateway and firewall devices are configured with a static route for the 10.0.0.0/8, 161.26.0.0/16 and 166.8.0.0/14 networks to the Back-end Customer Router (BCR). If you configure overlapping routes with those subnets, validate that you have also configured PBR or a similar service. Otherwise, consider using different IP space that doesn't overlap with our service networks for your VPNs or tunnels.
If this policy exists, then any existing Redirect to url and Redirect to pool policies do not apply. Also, if there are any existing Redirect to https policies, then you cannot create any new Redirect to url and Redirect to pool policies.

If no HTTPS redirect policy exists, then any policies set to Redirect to url are evaluated after Reject.

Finally, policies set to Redirect to pool are evaluated last.

Within each action category, policies are evaluated in ascending order of priority (lowest to highest). Only one action of REDIRECT_HTTPS is allowed per listener, and it takes precedence over all other policies except REJECT. As a result, the concept of "priority" does not apply.



 Layer 7 policy properties 



 Property Description 

 Name The name of the policy. Each policy must have a unique name. 
 Action The action to take when the rules match. The actions are REJECT, REDIRECT_HTTPS, REDIRECT_URL, and REDIRECT_POOL. REDIRECT_HTTPS action is supported by API only. 
 Priority Within each action category, policies are evaluated in ascending order of priority. This field is not applicable for REDIRECT_HTTPS because only one such action is applicable per listener. 
 Redirect URL The URL to which traffic is redirected, if the action is set to REDIRECT_URL. Also, the HTTPS listener UUID to which traffic is to be redirected, if the action is set to REDIRECT_HTTPS. 
 Redirect L7 Pool The pool of servers to which traffic is sent, if the action is set to REDIRECT_POOL. 
 Protocol The front-end application port to which the policy is applied. 







 Layer 7 rule 

Layer 7 rules define a portion of the incoming traffic that is to be matched with specific values.



* Adding L7 rules is not allowed for any L7 policy with REDIRECT_HTTPS action.
* If the incoming traffic matches the specified value of a rule, then the rule evaluates to true.
* Layer 7 rules are always associated with a Layer 7 policy. Multiple Layer 7 rules can be associated with the same Layer 7 policy.
You can also specify which resource group the policy is applied to in the command.



 Creating rules by using the API 

Review the following example requests to create rules. For more information about the v1/rules API, see the [API docs](https://cloud.ibm.com/apidocs/context-based-restrictionscreate-rule).

After you create a rule, it might take up to 10 minutes before you can update that rule.

The following example payload creates a rule that protects the Virtual Server Instances and allows access only from the specified network zone via a private endpoint.

{
"contexts": [
{
"attributes":
{
"name": "endpointType",
"value": "private"
},
{
"name": "networkZoneId",
"value": "45ec64065b7c2bf84b3edec803335111"
}
]
}
],
"resources": [
{
"attributes":
{
"name": "resourceGroupId",
"value": "1171749e3a8545069d04e6fca1ded18f"
},
{
"name": "serviceName",
"value": "is"
},
{
"name": "instanceId",
"value": ""
}
]
}
]
}





 Creating rules by using the CLI 



1. To create rules from the CLI, [install the CBR CLI plug-in](https://cloud.ibm.com/docs/account?topic=cli-cbr-plugininstall-cbr-plugin).
2. Use the ibmcloud cbr rule-create[command](https://cloud.ibm.com/docs/account?topic=cli-cbr-plugincbr-cli-rule-create-command) to create CBR rules.
kind: GlobalNetworkPolicy
metadata:
name: allowlist
spec:
applyOnForward: true
preDNAT: true
ingress:
- action: Allow
destination:
nets:
- <loadbalancer_IP>/32
ports:
- 80
protocol: TCP
source:
nets:
- <client_address>/32
selector: ibm.role=='worker_public'
order: 500
types:
- Ingress
Show more
5. Apply the policy.



* Linux:

calicoctl apply -f filepath/allowlist.yaml
* Windows and OS X:

calicoctl apply -f filepath/allowlist.yaml --config=filepath/calicoctl.cfg



Your system's IP address is now allowed.
6. Using the value from your cheat sheet, verify that you now can access the public NLB IP address.

curl --connect-timeout 10 <loadbalancer_IP>:80
7. If you have access to another system that has a different IP address, try to access the NLB from that system.

curl --connect-timeout 10 <loadbalancer_IP>:80

The connection times out because that system's IP address isn't allowed.



At this point, all traffic to the public node ports and NLB is blocked. Only traffic from your allowed system IP is allowed.





 Step 4: Deny incoming traffic from specific IPs to the NLB 

In the previous lesson, you blocked all traffic and allowed only a few IPs. That scenario works well for testing purposes when you want to limit access to only a few controlled source IP addresses. However, the PR firm has apps that need to be widely available to the public. You need to make sure that all traffic is permitted except for the unusual traffic you are seeing from a few IP addresses. A denylist is useful in a scenario like this one because it can help you prevent an attack from a small set of IP addresses.
Scoping a rule to a specific resource group is available only for rules that protect the cluster API type. If you use the CLI, you can specify the --resource-group-id option to protect resources in a specific resource group. If you use the UI, you can specify the Resource group in the resource attributes.

Instance
: Protects a specific instance. If you include an instance in your context-based restrictions rule, resources in the network zones that you associate with the rule can interact only with resources in that instance. Scoping a rule to a specific instance is available only for rules that protect the cluster API type. If you use the CLI, you can specify the --service-instance option to protect instances in a specific resource group. If you use the UI, you can specify the Service instance in the resource attributes.







 Creating network zones 

A network zone represents an allowlist of IP addresses where an access request is created. It defines a set of one or more network locations that are specified by the following attributes:



* IP addresses, which include individual addresses, ranges, or subnets.
* VPCs





 Creating network zones in the UI 



1. Go to Manage > Context-based restrictions in the IBM Cloud® console.
2. Select Network zones.
3. Click Create.
4. Name your network zone and provide a description.
5. Enter your Allowed IP addresses. You can enter a single IP address, a range of IP addresses, or a single CIDR.

The Denied IP addresses field is optional and should include only exceptions that are contained within the IP ranges you provide in the allowed IP addresses field.
6. Choose your Allowed VPCs, selecting as many as you like.
7. Reference a service: You can select Cloud Databases as a source service for context-based restrictions, but not as a target service. For example, you can provision a Cloud Databases deployment using BYOK from IBM® Key Protect for IBM Cloud®. In this example, Cloud Databases is the source formation and IBM® Key Protect for IBM Cloud® is the target formation.