Secure EJBCA with Network Policies

This outlines the key considerations for planning and configuring network policies for Helm chart-based EJBCA deployments.

As of version 9.1, the EJBCA Helm chart includes support for Network Policies, allowing you to configure rules to control traffic flow between EJBCA, its peers, external services, and other components, thereby enhancing security.

Proper planning of network policies is crucial to ensure that the EJBCA service remains accessible and functional. The EJBCA Helm chart allows applying these policies automatically, eliminating the need for manual configuration after deployment. Misconfigurations may render the EJBCA service unreachable, so carefully define network policies according to your environment and review your policies before applying them.

Plan Network Policies

When planning network policies, consider the necessary traffic flows and security requirements of your EJBCA setup.

Ports

The EJBCA pod can host up to three containers: EJBCA, Nginx, and an optional Hardware Security Module (HSM) sidecar. Ensure the necessary ports are accessible based on your configuration:

Port 443 (HTTPS) and Port 80 (HTTP, if non-encrypted traffic is allowed) when:
- A Load Balancer is used to access EJBCA via the Nginx sidecar (recommended).
- Other applications within the cluster communicate with EJBCA, including EJBCA instances communicating with peers.
Port 8082 for direct Ingress access (not recommended in production environments).

When configuring policies for EJBCA traffic between instances, you can use the label app.kubernetes.io/name: ejbca in podSelector.matchLabels to identify EJBCA pods.

Ingress Traffic

To control incoming traffic to EJBCA, you may configure network policies depending on the connection source.

External Traffic

To allow external access, configure policies based on whether you use a LoadBalancer or an Ingress Controller.

Ingress Controller:
- Allow traffic from the namespace where the Ingress Controller resides. Example:
  YAML
```
   - namespaceSelector:
       matchLabels:
         kubernetes.io/metadata.name: ingress
```

LoadBalancer:
- Specify the allowed IP address ranges for incoming traffic. Example:
  YAML
```
   from:
     - ipBlock:
         cidr: 192.168.122.0/16
```

EJBCA Peer Nodes (RA/VA)

Peer installations of EJBCA Registration Authority (RA) and Validation Authority (VA) nodes should be accessible by EJBCA Certificate Authority (CA) nodes.

Other Applications

Define policies to permit your business applications to interact with EJBCA running in Kubernetes and access EJBCA for automation tasks.

Egress Traffic

EJBCA requires outbound (egress) traffic to various services, such as databases, HSMs, and peer nodes. Configure the following egress policies as applicable to your setup:

Database: Kubernetes internal or external database used by EJBCA.
HSM: If using an external Hardware Security Module (HSM), allow access to the corresponding IP address or range.
Peer Instances: Allow communication between CA and peer (RA/VA) nodes.
Use Case-Specific Services:
- Email Notifications: If EJBCA is configured for email alerts, allow traffic to the mail server.
- ACME Protocol: EJBCA communicates with external servers and/or DNS caches for HTTP or DNS based domain validation.
- MSAE Protocol: Allow communication with services like Active Directory Certificate Services (ADCS).
- Publishers: Different publishers such as LDAP or CertSafe may require access to external servers, typically from the CA node.
- CAA Validation: Domain validation requires access to the external domain during the certificate request phase. Add the corresponding domain’s IP range to the CA Node’s policy.
- OAuth: If EJBCA integrates with an OAuth provider, ensure the policy allows outbound traffic to the OAuth server's API endpoints.

Example Network Policies

The following provides network policy examples.

Example 1: Network Policies for EJBCA RA using an Ingress Controller

Only Ingress rules are shown.

The following example shows a network policy for a scenario where an Ingress controller is used to route traffic to an EJBCA RA:

YAML

networkPolicy:
  policyTypes:
    - Ingress
  ingress:
    - from:
      # Allow traffic from the CA namespace
      - namespaceSelector:
          matchLabels:
            kubernetes.io/metadata.name: ejbca-ca
      # Allow traffic from the Ingress controller namespace
      - namespaceSelector:
          matchLabels:
            kubernetes.io/metadata.name: ingress

Note that only Ingress rules are shown.

Example 2: Network Policies for EJBCA RA using a LoadBalancer

Only Ingress rules are shown.

The following example shows a network policy for a scenario where a LoadBalancer is used to route traffic to an EJBCA RA:

YAML

networkPolicy:
  policyTypes:
    - Ingress
  ingress:
    # Allow access from specific client IP ranges, 
    # such as admin access or devices using EST, CMP, etc.
    - from:
      - ipBlock:
          cidr: 192.168.122.0/16
      # Allow traffic from the CA namespace
      - namespaceSelector:
          matchLabels:
            kubernetes.io/metadata.name: ejbca-ca

Following these guidelines and examples, you can secure your EJBCA deployment with network policies tailored to your environment.