Securing Applications in ROKS Cluster

In the dynamic landscape of cloud computing, ensuring the security of your applications is paramount. This is particularly true when dealing with a Red Hat OpenShift Kubernetes Service (ROKS) cluster, where applications may be exposed to the public internet. In this article, we will explore how to enhance the security of your applications by routing traffic through edge nodes in the ROKS cluster. Additionally, we will integrate Istio Egress Gateway to manage outbound traffic for even greater control and security.

For detailed Istio Egress Gateway configurations and use cases, you can refer to the following Git repository.

Understanding the Challenge

By default, applications deployed in a ROKS cluster may be accessible from the public internet. To strengthen security, we aim to direct all external traffic through edge nodes, effectively bypassing the default worker nodes. This ensures that the applications are shielded from direct exposure to potential threats on the public internet.

Istio Egress Gateway Integration

Step 1: Identifying Edge Nodes

1. Accessing ROKS cluster dashboard: Start by accessing the ROKS cluster dashboard through the Cloud console. 
2. Identifying edge nodes: Navigate to the cluster details and identify the edge nodes. Edge nodes typically act as the entry point for external traffic, providing an additional layer of security.

Step 2: Removing Public Gateway for Default Nodes

1. Accessing node configuration: In the ROKS cluster dashboard, locate the configuration settings for the default worker nodes. 
2. Removing public gateway: Modify the network configuration of default nodes to remove the public gateway. This step ensures that external traffic will no longer be directed to the default nodes.

Step 3: Configuring Routing via Edge Nodes and Istio Egress Gateway

In an OpenShift cluster, Istio Egress Gateway plays a crucial role in managing outbound traffic from services within the cluster to external services. It focuses on controlling and routing traffic leaving the cluster. Here, in this example, we are setting Egress Gateway to allow outbound connection to “ibm.com” from our application pods.
If you want to allow a list of different domains for egress connection, replace “ibm.com” with the required domain name in all the resources below. Copy and paste the below resources in specific files and apply them using “oc apply -f <file-name>.”

• Gateway: Configured to capture outgoing traffic and direct it to the Egress Gateway for processing.

apiVersion: networking.istio.io/v1beta1
kind: Gateway
metadata:
  name: istio-egressgateway
spec:
  selector:
    istio: egressgateway
  servers:
  - hosts:
    - ibm.com
    port:
      name: tls
      number: 443
      protocol: TLS
    tls:
      mode: PASSTHROUGH

• ServiceEntry: Used to define external services that microservices within the cluster need to communicate with.

apiVersion: networking.istio.io/v1beta1
kind: ServiceEntry
metadata:
  name: serviceentry
spec:
  hosts:
    - ibm.com
  location: MESH_EXTERNAL
  ports:
  - name: tls
    number: 443
    protocol: TLS
  resolution: DNS

• VirtualService: Configured to define routing rules for outgoing traffic, specifying how requests to external services should be processed.

# Below Hostname "istio-egressgateway.istio-system.svc.cluster.local" is given, 
# assuming your gateway pods are running in istio-system namespace. 
# Else replace "istio-system" based on your setup.
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: ibm-vs
spec:
  exportTo:
  - .
  - istio-system
  gateways:
  - mesh
  - istio-egressgateway
  hosts:
  - ibm.com
  tls:
  - match:
    - gateways:
      - mesh
      port: 443
      sniHosts:
      - ibm.com
    route:
    - destination:
        host: istio-egressgateway.istio-system.svc.cluster.local
        port:
          number: 443
  - match:
    - gateways:
      - istio-egressgateway
      port: 443
      sniHosts:
      - ibm.com
    route:
    - destination:
        host: ibm.com
        port:
          number: 443

• DestinationRule: Defines policies for outgoing traffic to external services, influencing how the Egress Gateway communicates with those services

# Below Hostname "istio-egressgateway.istio-system.svc.cluster.local" is given, 
# assuming your gateway pods are running in istio-system namespace.
# Else replace "istio-system" based on your setup.
apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
  name: dr-egressgateway
spec:
  host: istio-egressgateway.istio-system.svc.cluster.local

3.2. Implementing Network Policies

Define network policies that enforce the desired routing rules. This can include specifying that traffic must pass through the edge nodes before reaching the application pods.

Conclusion

Securing applications in a ROKS cluster from the public internet requires a thoughtful approach to routing traffic. By removing the public gateway for default nodes, configuring routing through edge nodes, and integrating Istio Egress Gateway, you can significantly enhance the security posture of your applications. Always remember to test these changes in a controlled environment to ensure the uninterrupted functionality of your applications while safeguarding them against potential security threats.