- What's New
- Product Bulletin
- Service Overview
- Billing
- Getting Started
-
User Guide
- Application Service Mesh
- Buying a Service Mesh
- Mesh Management
- Service Management
- Gateway Management
- Grayscale Release
- Mesh Configuration
- Traffic Management
- Security
-
Best Practices
- Upgrading Data Plane Sidecars Without Service Interruption
- Service Governance for Dubbo-based Applications
- Reserving Source IP Address for Gateway Access
- Creating a Service Mesh with IPv4/IPv6 Dual Stack Enabled
- How Do I Query Application Metrics in AOM?
- Reducing the Agency Permissions of ASM Users
- Istio-ingressgateway HA Configuration
-
FAQs
- Service Mesh Cluster
-
Mesh Management
- Why Cannot I Create a Mesh for My Cluster?
- Why Are Exclusive Nodes Still Exist After Istio Is Uninstalled?
- How Do I Upgrade ICAgent?
- How Do I Enable Namespace Injection for a Cluster?
- How Do I Disable Sidecar Injection for Workloads?
- What Can I Do If A Pod Cannot Be Started Due to Unready Sidecar
- How Do I Handle a Canary Upgrade Failure?
-
Adding a Service
- What Do I Do If an Added Gateway Does Not Take Effect?
- Why Does It Take a Long Time to Start the Demo Application in Experiencing Service Mesh in One Click?
- Why Cannot I Access the page of the Demo Application After It Is Successfully Deployed?
- Why Cannot I Select the Corresponding Service When Adding a Route?
- How Do I Inject a Sidecar for the Pod Created Using a Job or CronJob?
- Performing Grayscale Release
-
Managing Traffic
- Why Are the Created Clusters, Namespaces, and Applications Not Displayed on the Traffic Management Page?
- How Do I Change the Resource Requests of the istio-proxy Container?
- Does ASM Support HTTP/1.0?
- How Can I Block Access from Some IP Address Ranges or Ports for a Service Mesh?
- How Do I Configure max_concurrent_streams for a Gateway?
- How Do I Fix Compatibility Issues Between Istio CNI and Init Containers?
-
Monitoring Traffic
- Why Cannot I View Traffic Monitoring Data Immediately After a Pod Is Started?
- Why Are the Latency Statistics on the Dashboard Page Inaccurate?
- Why Is the Traffic Ratio Inconsistent with That in the Traffic Monitoring Chart?
- Why Can't I Find Certain Error Requests in Tracing?
- Why Cannot I Find My Service in the Traffic Monitoring Topology?
- How Do I Connect a Service Mesh to Jaeger or Zipkin for Viewing Traces?
- Videos
-
More Documents
-
User Guide (ME-Abu Dhabi Region)
- Service Overview
- Getting Started
- User Guide
-
FAQs
- Service Mesh Cluster
- Mesh Management
-
Adding a Service
- What Do I Do If an Added Gateway Does Not Take Effect?
- Why Does It Take a Long Time to Start the Demo Application in Experiencing Service Mesh in One Click?
- Why Cannot I Access the page of the Demo Application After It Is Successfully Deployed?
- Why Cannot I Select the Corresponding Service When Adding a Route?
- Performing Grayscale Release
-
User Guide (ME-Abu Dhabi Region)
- General Reference
Copied.
How Can I Block Access from Some IP Address Ranges or Ports for a Service Mesh?
Scenarios
In some scenarios, you may want to specify IP address ranges that need to be blocked by a service mesh proxy. In some scenarios, you may want to specify ports to block requests. This section describes how to block access from some IP address ranges and ports.
Workload Configuration for Blocking Access from Some IP Address Ranges
Modify the deployment file to block some IP address ranges.
Run the kubectl edit deploy –n user_namespace user_deployment command.
1. In deployment.spec.template.metadata.annotations, use traffic.sidecar.istio.io/includeOutboundIPRanges to specify IP address ranges to be blocked.
2. In deployment.spec.template.metadata.annotations, use traffic.sidecar.istio.io/excludeOutboundIPRanges to specify IP address ranges that are allowed.
Note: The preceding operations will cause rolling upgrades of service containers.
Workload Configuration for Blocking Ingress and Egress Traffic over Some Ports
Modify the deployment file to block ingress and egress traffic over some ports.
Run the kubectl edit deploy –n user_namespace user_deployment command.
1. In deployment.spec.template.metadata.annotations, use traffic.sidecar.istio.io/excludeInboundPorts to specify the ports that allow the ingress traffic.
2. In deployment.spec.template.metadata.annotations, use traffic.sidecar.istio.io/includeInboundPorts to specify the ports that block the ingress traffic.
3. In deployment.spec.template.metadata.annotations, use traffic.sidecar.istio.io/excludeOutboundPorts to specify the ports that allow the egress traffic.
4. In deployment.spec.template.metadata.annotations, use traffic.sidecar.istio.io/includeOutboundPorts to specify the ports that block the egress traffic.
Note: The preceding operations will cause rolling upgrades of service containers.
Verification
The configurations take effect in iptables of containers. Run the following commands to check whether the configurations take effect.
- Log in to the node where the workload is running and run the docker ps command to find the pause container and view the container ID.
- Run the docker inspect <CONTAINER_ID> | grep –i pid command to view the process ID.
- Run the nsenter –t <PID> -n bash command to go to the namespace of the container.
- Run the iptables iptables –t nat –L –n –v command to check whether the configurations take effect for specified IP address ranges and ports.
Feedback
Was this page helpful?
Provide feedbackThank you very much for your feedback. We will continue working to improve the documentation.See the reply and handling status in My Cloud VOC.
For any further questions, feel free to contact us through the chatbot.
Chatbot