Network Policies Documentation¶

The bb-common Helm chart provides a comprehensive network policy framework that simplifies the creation and management of Kubernetes NetworkPolicies. This feature enables fine-grained control over network traffic between pods, namespaces, and external resources.

Table of Contents¶

Network Policies Documentation
Table of Contents
Quick Start
Overview
Configuration Syntax
How It Works
Configuration
Built-in Definitions
Examples
Advanced Features
Labels and Annotations
- Built-in Labels and Annotations
- Customizing Labels and Annotations
Troubleshooting

Quick Start¶

To enable network policies and create a simple egress rule:

networkPolicies:
  enabled: true
  egress:
    from:
      app:
        to:
          k8s:
            backend/api:8080: true # Include port for precise control

This creates a policy allowing pods labeled app.kubernetes.io/name: app to connect to pods labeled app.kubernetes.io/name: api in the backend namespace on port 8080.

Note about YAML syntax: The keys like backend/api:8080: might look unusual, but they are perfectly valid YAML. The slash and colon are allowed in YAML keys when used as shown. This syntax enables our powerful shorthand notation while keeping your configuration concise and readable.

Overview¶

The network policy feature in bb-common provides:

Declarative syntax for defining network policies
Shorthand notations for common patterns
Default policies for common security requirements
Reusable definitions for frequently used rules
Automatic policy naming based on rules
Support for raw NetworkPolicy specs when needed

Configuration Syntax¶

The chart uses a structured YAML format with three main rule types:

Kubernetes Rules (`k8s`)¶

Kubernetes rules allow traffic between pods and namespaces. The format for the rule key is: [<identity>@]<namespace>/<pod>:<port>

Examples:

networkPolicies:
  egress:
    from:
      my-app:
        to:
          k8s:
            backend/api:8080: true # Specific pod and port
            backend/api: true # Any port on api pod
            backend/*: true # Any pod in backend namespace
            backend/*:8080: true # Any pod on specific port
            "*/prometheus:9090": true # Prometheus in any namespace
            "*/*": true # Any pod in any namespace

For ingress rules with identity-based authorization (requires istio.authorizationPolicies.generateFromNetpol: true):

istio:
  authorizationPolicies:
    generateFromNetpol: true
networkPolicies:
  ingress:
    to:
      api:
        from:
          k8s:
            frontend/web: true # NetworkPolicy only
            api-sa@backend/worker: true # NetworkPolicy + AuthorizationPolicy

Overriding the remote selector¶

The <pod> token maps to a podSelector of app.kubernetes.io/name: <pod>. When the peer is selected by a different label (e.g. an Istio ambient waypoint pod, labelled gateway.networking.k8s.io/gateway-name), set the rule value to a map with a podSelector and/or namespaceSelector to override the defaults instead of falling back to a literal rule. The pod token is still used for the generated resource name:

networkPolicies:
  ingress:
    to:
      authservice:10003:
        from:
          k8s:
            # default selector: app.kubernetes.io/name: podinfo
            podinfo/podinfo: true
            # overridden selector: matches the waypoint pod by gateway-name
            podinfo/podinfo-waypoint:
              podSelector:
                matchLabels:
                  gateway.networking.k8s.io/gateway-name: podinfo-waypoint

The same podSelector/namespaceSelector override works for egress to peers.

CIDR Rules (`cidr`)¶

CIDR rules allow traffic to/from IP address ranges. The format is: <ip-range>[:<port>]

networkPolicies:
  egress:
    from:
      my-app:
        to:
          cidr:
            10.0.0.0/8:443: true # Private network HTTPS
            192.168.1.0/24:22: true # SSH to local network
            0.0.0.0/0:443: true # Internet HTTPS (metadata endpoint auto-blocked by default)
            52.84.23.62/32:[80,443]: true # Multiple ports to specific IP

Note: When using 0.0.0.0/0, the commonly-used cloud metadata endpoint address 169.254.169.254/32 is automatically excluded.

Definition Rules (`definition`)¶

Definitions are reusable rule sets. You can use built-in definitions or create custom ones:

networkPolicies:
  egress:
    definitions:
      my-custom-api:
        to:
          k8s:
            namespace/custom-api:8000
    from:
      my-app:
        to:
          definition:
            kubeAPI: true # Built-in: Kubernetes API access
            my-custom-api: true # Custom definition (outlined in a section below)

  ingress:
    to:
      my-app:
        from:
          definition:
            gateway: true # Built-in: Istio ingress gateway
            monitoring: true # Built-in: Prometheus

Built-in definitions are outlined below. Compatible ingress definitions also generate AuthorizationPolicies when istio.authorizationPolicies.generateFromNetpol is enabled. Exact namespace selectors and IP blocks are translated to Istio sources; unsupported selectors and named ports remain NetworkPolicy-only.

Literal Rules (`literal`)¶

For complex scenarios, you can provide raw NetworkPolicy spec fragments:

networkPolicies:
  egress:
    from:
      my-app:
        to:
          literal:
            complex-rule:
              enabled: true
              spec:
                - to:
                    - namespaceSelector:
                        matchExpressions:
                          - key: environment
                            operator: In
                            values: ["production", "staging"]
                  ports:
                    - port: 443
                      protocol: TCP

Port Specifications¶

Ports are a critical part of network policies and should be specified whenever possible for precise traffic control:

For Egress (outbound) - Port goes on the destination:

backend/api:8080: true # Single port
backend/api:[80,443]: true # Multiple ports
backend/api:8080-8090: true # Port range
10.0.0.0/8:443: true # CIDR with port

For Ingress (inbound) - Port goes on the local pod:

api: true # Local pod accepts all ports (not recommended)
api:8080: true # Local pod accepts on port 8080
api:[80,443]: true # Local pod accepts on multiple ports
web:8080-8090: true # Local pod accepts on port range

Important: Always specify ports unless you explicitly need to allow all ports. This follows the principle of least privilege.

How It Works¶

Selector Behavior¶

The network policy framework uses specific label selectors for identifying pods and namespaces:

Namespace Selectors: Match on the actual namespace name using the kubernetes.io/metadata.name label
Pod Selectors: Match on the app.kubernetes.io/name label by default

For example, the shorthand backend/api translates to:

Namespace selector: matchLabels: { "kubernetes.io/metadata.name": "backend" }
Pod selector: matchLabels: { "app.kubernetes.io/name": "api" }

Shorthand to NetworkPolicy Translation¶

Here’s how shorthand syntax translates into Kubernetes NetworkPolicy resources:

Example 1: Basic Egress Rule¶

# Shorthand
networkPolicies:
  egress:
    from:
      frontend:
        to:
          k8s:
            backend/api:8080: true

# Generates this NetworkPolicy
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-egress-from-frontend-to-ns-backend-pod-api-tcp-port-8080
spec:
  podSelector:
    matchLabels:
      app.kubernetes.io/name: frontend
  policyTypes:
    - Egress
  egress:
    - to:
        - namespaceSelector:
            matchLabels:
              kubernetes.io/metadata.name: backend
          podSelector:
            matchLabels:
              app.kubernetes.io/name: api
      ports:
        - port: 8080
          protocol: TCP

Example 2: Ingress Rule with Port on Local Pod¶

# Shorthand (note: port is on the local pod identifier)
networkPolicies:
  ingress:
    to:
      api:8080:
        from:
          k8s:
            frontend/web: true

# Generates this NetworkPolicy
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-ingress-to-api-tcp-port-8080-from-ns-frontend-pod-web
spec:
  podSelector:
    matchLabels:
      app.kubernetes.io/name: api
  policyTypes:
    - Ingress
  ingress:
    - from:
        - namespaceSelector:
            matchLabels:
              kubernetes.io/metadata.name: frontend
          podSelector:
            matchLabels:
              app.kubernetes.io/name: web
      ports:
        - port: 8080
          protocol: TCP

Important: For ingress rules, ports are specified on the local pod (the destination), not in the remote identifier. This is because ingress rules define which ports on the local pod accept traffic.

Waypoint mirroring: in ambient mode, ingress k8s entries whose workload is fronted by an authservice-protected route are additionally mirrored onto the shared waypoint (a netpol on HBONE 15008 plus a Service-targetRefs AuthorizationPolicy). See Waypoint Mirroring of Declared Clients in the routes documentation.

Configuration¶

Enabling Network Policies¶

Network policies are disabled by default. Enable them by setting:

networkPolicies:
  enabled: true

Basic Egress Rules¶

Egress rules control outbound traffic from pods. Always specify ports for security:

networkPolicies:
  egress:
    from:
      frontend: # Pods with label app.kubernetes.io/name: frontend
        to:
          k8s:
            backend/api:8080: true # API on specific port
            cache/redis:6379: true # Redis cache
          cidr:
            52.84.0.0/16:443: true # External HTTPS API

Port placement: For egress rules, ports are specified on the destination (where traffic is going).

Basic Ingress Rules¶

Ingress rules control inbound traffic to pods. Port specifications go on the receiving pod:

networkPolicies:
  ingress:
    to:
      api:8080: # API pod accepts traffic on port 8080
        from:
          k8s:
            frontend/web: true # From frontend web pods
            monitoring/prometheus: true # From Prometheus

      database:5432: # Database accepts on PostgreSQL port
        from:
          k8s:
            backend/api: true # Only from API pods

Port placement: For ingress rules, ports are specified on the local pod (where traffic is received).

Default Policies¶

The chart provides several default policies that implement common security patterns. These are all enabled by default when you enable network policies.

Egress Defaults¶

networkPolicies:
  egress:
    defaults:
      enabled: true # Enable all defaults (this is the default)
      # Or control individually:
      denyAll:
        enabled: true  # Deny all egress by default
      allowInNamespace:
        enabled: true  # Allow egress within the same namespace
      allowKubeDns:
        enabled: true  # Allow DNS resolution (TCP/UDP port 53)
      allowIstiod:
        enabled: true  # Allow sidecar-mode Istio control plane communication (TCP port 15012)

allowIstiod is not rendered when istio.ambient.enabled=true because workload control-plane connectivity shifts from pod sidecars to ztunnel.

Ingress Defaults¶

networkPolicies:
  ingress:
    defaults:
      enabled: true # Enable all defaults (this is the default)
      # Or control individually:
      denyAll:
        enabled: true # Deny all ingress by default
      allowInNamespace:
        enabled: true # Allow ingress from same namespace
      allowPrometheusToIstioSidecar:
        enabled: true # Allow ingress from prometheus in monitoring namespace for sidecar metrics (TCP port 15020)

Important: You only need to specify these in your values if you want to disable specific defaults. They are all enabled automatically.

Default Policy Hook Creation¶

networkPolicies:
  # Hook creation configuration for default policies
  defaultsAsHooks:
    enabled: false # Create hook versions of default policies IN ADDITION to regular versions (default: false)
    hooks: # Hook types (default: ["pre-install", "pre-upgrade", "post-delete"])
      - pre-install
      - pre-upgrade
      - post-delete
    weight: -5 # Hook execution weight (default: -5)
    deletePolicies: # Hook delete policies (default: ["hook-succeeded", "before-hook-creation"])
      - hook-succeeded
      - before-hook-creation

When defaultsAsHooks.enabled is true, the chart will create both regular NetworkPolicy resources and additional hook versions of each enabled default policy. The hook versions have -as-hook appended to their names and include the appropriate Helm hook annotations.

This allows default policies to be applied at specific lifecycle points (e.g., before application deployment) while maintaining the regular policies for ongoing enforcement.

Built-in Definitions¶

The chart includes pre-configured definitions for common scenarios:

Egress Definitions¶

kubeAPI: Allow access to Kubernetes API server
Includes common private network ranges: 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16
Performs a lookup to limit connectivity to the ports defined on the kubernetes service in the default namespace.

Ingress Definitions¶

gateway: Allow traffic from Istio ingress gateway
Namespace: istio-gateway
Pod labels: app: istio-ingressgateway, istio: ingressgateway
monitoring: Allow traffic from Prometheus
Namespace: monitoring
Pod labels: app.kubernetes.io/name: prometheus

Overriding the Default Definitions¶

You can override these default definitions in your values if necessary. Note that overriding a definition will replace that definition entirely. It will not be merged with the existing default definition.

This is what a definition override would look like for the kubeAPI default definition:

networkPolicies:
  egress:
    definitions:
      kubeAPI:
        to:
          - ipBlock:
              cidr: 172.16.100.0/24

Examples¶

Basic Web Application¶

A simple web application with proper port specifications:

networkPolicies:
  enabled: true

  # Web app receives traffic from the gateway
  ingress:
    to:
      web:8080: # Web server listens on port 8080
        from:
          definition:
            gateway: true

  # Web app connects to backend services
  egress:
    from:
      web:
        to:
          k8s:
            backend/api:3000: true # API service
            cache/redis:6379: true # Redis cache
          cidr:
            0.0.0.0/0:443: true # External HTTPS APIs

Microservices Architecture¶

A more complex setup with multiple services:

networkPolicies:
  enabled: true
  prependReleaseName: true # Prefix policy names with release name

networkPolicies:
  # Frontend service configuration
  ingress:
    to:
      frontend:8080:
        from:
          definition:
            gateway: true # Receive traffic from gateway on port 8080

  egress:
    from:
      frontend:
        to:
          k8s:
            backend/api:8080: true # Connect to API on port 8080

networkPolicies:
  # API service configuration
  egress:
    from:
      api:
        to:
          k8s:
            database/postgres:5432: true # Connect to database
          cidr:
            52.84.0.0/16:443: true # External API calls on port 443

networkPolicies:
  # Database configuration
  ingress:
    to:
      postgres:5432: # PostgreSQL port
        from:
          k8s:
            backend/api: true # Only accept from API service

Multi-Namespace Setup¶

When services span multiple namespaces:

networkPolicies:
  enabled: true

  # Allow all pods to connect to shared services with specific ports
  egress:
    from:
      "*": # Wildcard applies to all pods
        to:
          k8s:
            shared-services/cache:6379: true # Redis port
            shared-services/queue:5672: true # RabbitMQ port
            logging/elasticsearch:9200: true # Elasticsearch

  # API service with multiple access points
  ingress:
    to:
      api:8080: # HTTP API port
        from:
          k8s:
            frontend/*: true # Any pod from frontend namespace
            admin/dashboard: true # Admin dashboard access
      api:8443: # HTTPS API port
        from:
          k8s:
            external/gateway: true # External gateway only

Advanced Features¶

Once you’re comfortable with the basics, you can use these advanced features:

Protocol Support¶

Specify protocols when needed (TCP is default):

networkPolicies:
  egress:
    from:
      app:
        to:
          k8s:
            udp://dns-server/dns:53: true # UDP traffic
            tcp://backend/api:443: true # Explicit TCP

  ingress:
    to:
      udp://syslog:514: # UDP syslog receiver
        from:
          k8s:
            "*/*": true # Any pod from any namespace

Advanced Port Patterns¶

Beyond the basic port specifications, you can use more complex patterns:

networkPolicies:
  # Multiple ports array
  egress:
    from:
      app:
        to:
          k8s:
            backend/api:[8080,8443]: true # HTTP and HTTPS
            monitoring/stats:[9090,9100]: true # Multiple metric ports

  # Port ranges
  ingress:
    to:
      api:8080-8090: # Accept on port range
        from:
          k8s:
            frontend/*: true
      api:443: # Separate rule for HTTPS
        from:
          k8s:
            frontend/*: true
            monitoring/prometheus: true

  # Combining protocols with ports
  egress:
    from:
      dns-client:
        to:
          k8s:
            udp://kube-system/coredns:53: true # UDP DNS
            tcp://backend/api:443: true # Explicit TCP

Custom Pod Selectors¶

Override the default pod selector behavior:

networkPolicies:
  egress:
    from:
      my-app:
        podSelector: # Custom selector instead of app.kubernetes.io/name
          matchLabels:
            component: worker
            tier: backend
        to:
          k8s:
            database/postgres:5432: true # PostgreSQL port

Custom Definitions¶

Create reusable rule definitions:

networkPolicies:
  egress:
    definitions:
      external-api:
        to:
          - ipBlock:
              cidr: 52.84.0.0/16
        ports:
          - port: 443
            protocol: TCP
          - port: 8443
            protocol: TCP
    from:
      app:
        to:
          definition:
            external-api: true # Reference your definition

  ingress:
    definitions:
      internal-monitoring:
        from:
          - namespaceSelector:
              matchLabels:
                purpose: monitoring
            podSelector:
              matchLabels:
                app: prometheus
    to:
      app:9090: # Metrics port on local pod
        from:
          definition:
            internal-monitoring: true

Custom Labels and Annotations¶

The network policy framework provides flexible support for adding custom labels and annotations to generated NetworkPolicy resources. This is useful for integration with monitoring tools, policy management systems, or organizational requirements.

Local Key Labels and Annotations¶

Apply labels and annotations to all policies generated from a specific local key (source pod):

networkPolicies:
  egress:
    from:
      app:
        metadata:
          labels:
            policy-type: egress
            team: backend
          annotations:
            description: Egress policies for app service
            contact: backend-team@company.com
        to:
          k8s:
            backend/api:8080: true # Gets labels/annotations above
            backend/db:5432: true # Gets labels/annotations above
          cidr:
            52.84.0.0/16:443: true # Gets labels/annotations above

  ingress:
    to:
      api:8080:
        metadata:
          labels:
            policy-type: ingress
            service: api
          annotations:
            description: Ingress policies for API service
        from:
          k8s:
            frontend/web: true # Gets labels/annotations above
            admin/dashboard: true # Gets labels/annotations above

Remote Key Labels and Annotations¶

Apply labels and annotations to specific remote rules by configuring them on individual remote targets:

networkPolicies:
  egress:
    from:
      app:
        to:
          k8s:
            backend/api:8080:
              enabled: true
              metadata:
                labels:
                  priority: high
                  service-type: api
                annotations:
                  description: Critical API connection
            backend/cache:6379:
              enabled: true
              metadata:
                labels:
                  priority: medium
                  service-type: cache
                annotations:
                  description: Cache connection
          cidr:
            52.84.0.0/16:443:
              enabled: true
              metadata:
                labels:
                  external: true
                annotations:
                  description: External API access

  ingress:
    to:
      api:8080:
        from:
          k8s:
            frontend/web:
              enabled: true
              metadata:
                labels:
                  source-type: frontend
                annotations:
                  description: Frontend web traffic
          definition:
            monitoring:
              enabled: true
              metadata:
                labels:
                  source-type: monitoring
                annotations:
                  description: Prometheus metrics collection

Label and Annotation Override Behavior¶

When both local and remote labels/annotations are specified, the framework follows these rules:

Local labels/annotations are applied first
Remote labels/annotations override local ones when keys conflict
Unique keys from both local and remote are preserved

networkPolicies:
  egress:
    from:
      app:
        metadata:
          labels:
            shared-key: local-value # Will be overridden
            local-only: local-value # Will be preserved
          annotations:
            shared-annotation: local-value # Will be overridden
            local-only-annotation: local-value # Will be preserved
        to:
          k8s:
            backend/api:8080:
              enabled: true
              metadata:
                labels:
                  shared-key: remote-value # Overrides local value
                  remote-only: remote-value # Added to final policy
                annotations:
                  shared-annotation: remote-value # Overrides local value
                  remote-only-annotation: remote-value # Added to final policy

# Results in a policy with:
# labels:
#   shared-key: remote-value      # Remote override
#   local-only: local-value       # Local preserved
#   remote-only: remote-value     # Remote added
# annotations:
#   shared-annotation: remote-value      # Remote override
#   local-only-annotation: local-value   # Local preserved
#   remote-only-annotation: remote-value # Remote added

Support Across All Remote Types¶

Labels and annotations work with all remote rule types:

networkPolicies:
  egress:
    from:
      app:
        metadata:
          labels:
            app: my-app
        to:
          # Kubernetes rules
          k8s:
            backend/api:8080:
              enabled: true
              metadata:
                labels:
                  remote-type: k8s

          # CIDR rules
          cidr:
            10.0.0.0/8:443:
              enabled: true
              metadata:
                labels:
                  remote-type: cidr

          # Definition rules
          definition:
            kubeAPI:
              enabled: true
              metadata:
                labels:
                  remote-type: definition

          # Literal rules
          literal:
            custom-rule:
              enabled: true
              metadata:
                labels:
                  remote-type: literal
              spec:
                - to:
                    - ipBlock:
                        cidr: 192.168.1.0/24
                  ports:
                    - port: 443
                      protocol: TCP

Common Use Cases¶

Policy Management Integration:

networkPolicies:
  egress:
    from:
      app:
        metadata:
          labels:
            policy-manager: kustomize
            managed-by: platform-team
          annotations:
            policy-version: v1.2.0
            last-updated: 2024-01-15

Monitoring and Alerting:

networkPolicies:
  ingress:
    to:
      api:8080:
        metadata:
          labels:
            monitoring: enabled
            alert-level: critical
          annotations:
            prometheus.io/scrape: true
            alert-description: API service network policy

Compliance and Auditing:

networkPolicies:
  egress:
    from:
      payment-service:
        metadata:
          labels:
            compliance: pci-dss
            data-classification: sensitive
          annotations:
            audit-required: true
            compliance-framework: PCI-DSS v4.0

Helm Hook Integration:

Custom labels and annotations are particularly useful for Helm hook scenarios, allowing you to control the lifecycle and execution order of network policies relative to other resources:

networkPolicies:
  egress:
    from:
      app:
        metadata:
          labels:
            app.kubernetes.io/managed-by: Helm
          annotations:
            helm.sh/hook: pre-install,pre-upgrade
            helm.sh/hook-weight: -5
            helm.sh/hook-delete-policy: before-hook-creation
        to:
          k8s:
            database/postgres:5432:
              enabled: true
              metadata:
                annotations:
                  helm.sh/hook: post-install
                  helm.sh/hook-weight: 1
                  description: Database access after app deployment

This enables scenarios such as:

Pre-deployment policies: Apply restrictive policies before application deployment
Post-deployment access: Enable specific connections only after services are ready
Cleanup hooks: Remove temporary policies during upgrades or uninstalls
Weighted execution: Control the order of policy application relative to other resources

Spec Literals¶

For complex scenarios not covered by any of the shorthands, use a raw NetworkPolicy ingress/egress spec:

networkPolicies:
  egress:
    from:
      app:
        to:
          literal:
            prod-or-staging:
              enabled: true
              spec: # Raw Kubernetes NetworkPolicy egress spec
                - to:
                    - namespaceSelector:
                        matchExpressions:
                          - key: environment
                            operator: In
                            values: ["production", "staging"]
                      podSelector:
                        matchLabels:
                          tier: backend
                  ports:
                    - port: 443
                      protocol: TCP
                    - port: 8443
                      protocol: TCP

Additional Policies¶

For absolute control of the network policies, they can be provided directly.

networkPolicies:
  additionalPolicies: # Raw NetworkPolicy resources
    - name: custom-policy
      labels:
        custom: label
      annotations:
        description: Custom network policy
      spec:
        podSelector:
          matchLabels:
            role: frontend
        policyTypes:
          - Egress
        egress:
          - to:
              - ipBlock:
                  cidr: 10.0.0.0/8
            ports:
              - port: 443
                protocol: TCP

Authorization Policy Generation¶

When using Istio service mesh, you can automatically generate Istio AuthorizationPolicies alongside NetworkPolicies. This provides service mesh-level security using SPIFFE identity verification (for k8s rules with service accounts) or IP-based filtering (for CIDR rules).

Enable AuthorizationPolicy generation:

istio:
  authorizationPolicies:
    generateFromNetpol: true
networkPolicies:
  enabled: true
  ingress:
    to:
      api:
        from:
          k8s:
            backend/worker: true # NetworkPolicy only
            api-sa@backend/worker: true # NetworkPolicy + AuthorizationPolicy (SPIFFE)
          cidr:
            192.168.1.0/24: true # NetworkPolicy + AuthorizationPolicy (IP-based)
          definition:
            monitoring: true # NetworkPolicy + namespace AuthorizationPolicy

For comprehensive documentation on AuthorizationPolicy generation, including: - How generation works for k8s and CIDR rules - SPIFFE identity verification - IP-based access control with ipBlocks - Port handling and examples - Configuration options

See the Authorization Policies documentation.

Automatic Istio HBONE Support¶

When using Istio’s Ambient Mesh mode, pods that are enrolled in the mesh without a sidecar must allow traffic on the HBONE port (15008) for proper functionality.

The network policy framework injects this port into user-defined ingress and egress policies only when explicitly enabled. Big Bang should enable this for packages that need to receive or send HBONE traffic, including mixed-mode scenarios where this package is not ambient but still needs to allow HBONE traffic:

networkPolicies:
  hbonePortInjection:
    enabled: true

Labels and Annotations¶

Built-in Labels and Annotations¶

All generated policies automatically include these labels:

network-policies.bigbang.dev/source: bb-common
network-policies.bigbang.dev/direction: <egress|ingress>

They’ll also include various generated.network-policies.bigbang.dev annotations based on their exact configuration.

Customizing Labels and Annotations¶

The framework provides comprehensive support for adding custom labels and annotations to your network policies. This feature supports both local (applied to all policies from a source) and remote (applied to specific rules) configurations, with intelligent override behavior when both are specified.

For detailed information on using custom labels and annotations, see the Custom Labels and Annotations section in the Advanced Features.

Troubleshooting¶

Common issues and solutions:

Policies not created: Ensure networkPolicies.enabled: true
DNS resolution failing: Make sure allowKubeDns is not disabled in egress defaults
Sidecar-mode Istio communication blocked: Make sure allowIstiod is not disabled in egress defaults
Policy naming conflicts: Use prependReleaseName: true for multiple releases
Complex selectors not working: Use spec literals for advanced matching
Connection refused: Ensure you’ve specified the correct port in your rules
Partial connectivity: Check if you need multiple ports (e.g., [80,443])

For debugging, use:

# List all policies
kubectl get netpol -n <namespace>

# Describe a specific policy
kubectl describe netpol <policy-name> -n <namespace>

# Test connectivity
kubectl exec -n <namespace> <pod> -- curl <target>:<port>

# Test specific port connectivity
kubectl exec -n <namespace> <pod> -- nc -zv <target> <port>