Networking

MCaas has enabled multiple networking controls both inside and outside the EKS cluser to define a ruleset for allowing and restricting network traffic. External traffic from public Internet is routed through Netscalar which acts as the platform’s Firewall layer. Network traffic is load-balanced using an ELB and then directed to the EKS cluster through Istio configurations. Once the traffic has reached the cluster, the intra-service communication is managed by Calico network policies.

Network Boundaries and Terminology

MCaaS provides multiple layers of network control each with their own configuration. The below example configurations will help you determine which sections you should configure to meet your application’s needs.

Cluster Traffic

To enable intra-service (pod-to-pod) communication, you will configure a Calico Network Policy. This policy only controls network traffic within the cluster and blocks all traffic from leaving the cluster. The default behavior is to block all traffic to/from the pods so it must be explicitly allowed through the networkPolicy section in the HelmRelease chart.

networkPolicy:
  enabled: true
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          namespace: <namespace>
    - podSelector:
        matchLabels:
          app.kubernetes.io/instance: <service>-<environment>

Tip

The namespaceSelector is only required when services are communicating across namespaces

For full configuration options, see the documentation from Calico and Kubernetes

GSA Network Traffic

To expose an endpoint outside of the EKS cluster or make a UI accessible, you will need to expose it to the GSA network. Once exposed, this service will be able to communicate with other services on the GSA network on ports 80/443. This is accomplished through the istioIngress section of the HelmRelease chart.

istioIngress:
  enabled: true
  host: "<application>-<service>.<env>.<module>.<tenant>.mcaas.fcs.gsa.gov"

Note

A wildcard DNS entry and SSL certificates may likely have been created by default for your account. The specific patterns may vary slightly tenant to tenant. Tenant may control the lowest level sub-domain at the "application-service" variable position. The remainder of the url pattern is controled by MCaaS and will be either .env.module.tenant.mcaas.fcs.gsa.gov or .env.tenant.mcaas.fcs.gsa.gov depending on your use of multiple modules or not (not common to use various modules). Please create a service ticket if there are any questions on the valid DNS patterns in your environment or if you need to make changes to use additional module designations.

Note

If your service would like to commuicate on a port other than 80/443, you will need to submit a Firewall Change Request

External/Public Traffic

To make your service accessible to public Internet, you will need to provide a custom DNS entry (i.e. myservice.gsa.gov) through a SNT. It is the tenant responsibility to acquire a cert from GSA. You will attach this cert and key file to your ServiceNow request. Services should only be made public from the Staging and Production envrionments.

Action Items to implement an external route:

• Submit service now ticket for dns record (MCaaS can help to fill this out)
• Submit service now ticket for external certificate request; see instructions for how to do this
• Submit FCS support ticket for routing changes in Netscaler, include issued cert and private key (MCaaS/Robert can handle Netscaler side)
• Expose to external; see istio ingress example