LIGHT

  • News
  • Docs
  • Community
  • Reddit
  • GitHub

Network Policy

When http-sidecar is used, all the traffic to and from the pod should go through the sidecar for API invocation and invoke other APIs. Here is an example network policy on the Kubernetes cluster.

networkpolicy.yaml

kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: proxy-allow
  labels:
    app: api
spec:
  podSelector:
    matchLabels:
      app: api
  ingress:
  - from:
    - namespaceSelector: {}
      podSelector: {}
    ports:
    - protocol: TCP
      port: 8080

  egress:
  - to:
    ports:
    - protocol: TCP
      port: 8438
    - protocol: TCP
      port: 443
    - protocol: TCP
      port: 8443
    - protocol: TCP
      port: 53
    - protocol: UDP
      port: 53
  policyTypes:
  - Ingress
  - Egress              

For ingress rules, it allows both North-South traffic from the Internet with ingress-nginx, for example, and east-west traffic between APIs within the same Kubernetes cluster regardless of the namespace on port 8080.

For egress rules, we block all traffic by default and only allow certain ports to go outside. The following ports are examples for most organizations with the on-prem cluster.

Port 8438 is used for the sidecar to connect to the Control Pane for the service registry and discovery. Port 443 is used to interact with the OAuth 2.0 provider to get the JWK or JWT token. Port 8443 is an optional port used to proxy the request from the Kubernetes cluster to the OAuth 2.0 provider if a proxy is used. Port 53 is used to resolve the DNS name to IP address for OAuth 2.0 provider. Both TCP and UDP are opened here.

With the above network policy, we only allow Egress for certain ports. For some APIs, they might need to access databases or Kafka clusters etc. The solution is the define its API-specific network policy to add additional ports to the Egress. It means the API needs to have an overlay with a customized network policy YAML file. During the deployment, both the sidecar and the API-specific network policies will be deployed individually. The additional Egress ports in the API-specific policy will be opened when the namespaceSelector and podSelector match the filtering rules.

  • About Light
    • Overview
    • Testimonials
    • What is Light
    • Features
    • Principles
    • Benefits
    • Roadmap
    • Community
    • Articles
    • Videos
    • License
    • Why Light Platform
  • Getting Started
    • Get Started Overview
    • Environment
    • Light Codegen Tool
    • Light Rest 4j
    • Light Tram 4j
    • Light Graphql 4j
    • Light Hybrid 4j
    • Light Eventuate 4j
    • Light Oauth2
    • Light Portal Service
    • Light Proxy Server
    • Light Router Server
    • Light Config Server
    • Light Saga 4j
    • Light Session 4j
    • Webserver
    • Websocket
    • Spring Boot Servlet
  • Architecture
    • Architecture Overview
    • API Category
    • API Gateway
    • Architecture Patterns
    • CQRS
    • Eco System
    • Event Sourcing
    • Fail Fast vs Fail Slow
    • Integration Patterns
    • JavaEE declining
    • Key Distribution
    • Microservices Architecture
    • Microservices Monitoring
    • Microservices Security
    • Microservices Traceability
    • Modular Monolith
    • Platform Ecosystem
    • Plugin Architecture
    • Scalability and Performance
    • Serverless
    • Service Collaboration
    • Service Mesh
    • SOA
    • Spring is bloated
    • Stages of API Adoption
    • Transaction Management
    • Microservices Cross-cutting Concerns Options
    • Service Mesh Plus
    • Service Discovery
  • Design
    • Design Overview
    • Design First vs Code First
    • Desgin Pattern
    • Service Evolution
    • Consumer Contract and Consumer Driven Contract
    • Handling Partial Failure
    • Idempotency
    • Server Life Cycle
    • Environment Segregation
    • Database
    • Decomposition Patterns
    • Http2
    • Test Driven
    • Multi-Tenancy
    • Why check token expiration
    • WebServices to Microservices
  • Cross-Cutting Concerns
    • Concerns Overview
  • API Styles
    • Light-4j for absolute performance
    • Style Overview
    • Distributed session on IMDG
    • Hybrid Serverless Modularized Monolithic
    • Kafka - Event Sourcing and CQRS
    • REST - Representational state transfer
    • Web Server with Light
    • Websocket with Light
    • Spring Boot Integration
    • Single Page Application
    • GraphQL - A query language for your API
    • Light IBM MQ
    • Light AWS Lambda
    • Chaos Monkey
  • Infrastructure Services
    • Service Overview
    • Light Proxy
    • Light Mesh
    • Light Router
    • Light Portal
    • Messaging Infrastructure
    • Centralized Logging
    • COVID-19
    • Light OAuth2
    • Metrics and Alerts
    • Config Server
    • Tokenization
    • Light Controller
  • Tool Chain
    • Tool Chain Overview
  • Utility Library
  • Service Consumer
    • Service Consumer
  • Development
    • Development Overview
  • Deployment
    • Deployment Overview
    • Frontend Backend
    • Linux Service
    • Windows Service
    • Install Eventuate on Windows
    • Secure API
    • Client vs light-router
    • Memory Limit
    • Deploy to Kubernetes
  • Benchmark
    • Benchmark Overview
  • Tutorial
    • Tutorial Overview
  • Troubleshooting
    • Troubleshoot
  • FAQ
    • FAQ Overview
  • Milestones
  • Contribute
    • Contribute to Light
    • Development
    • Documentation
    • Example
    • Tutorial
“Network Policy” was last updated: November 3, 2021: fixes #307 update service document for http-sdiecar and kafka-sidecar (3fcb1ff)
Improve this page
  • News
  • Docs
  • Community
  • Reddit
  • GitHub
  • About Light
  • Getting Started
  • Architecture
  • Design
  • Cross-Cutting Concerns
  • API Styles
  • Infrastructure Services
  • Tool Chain
  • Utility Library
  • Service Consumer
  • Development
  • Deployment
  • Benchmark
  • Tutorial
  • Troubleshooting
  • FAQ
  • Milestones
  • Contribute