Skip to content

MMCloud Security Architecture

Default VPC

Every AWS account includes a default VPC in each region. Each default VPC is a CIDR block of private IP addresses (172.31.0.0/16). (RFC 1918 reserves three blocks of IP addresses that are not routable in the public Internet.) The VPC is divided into /20 subnets, one for each Availability Zone in the region.

The preferred procedure is to deploy OpCenter in a VPC that you create specifically for MMCloud (not the default VPC). If you use the default VPC, the OpCenter is created in one subnet and is assigned a private IP address from the /20 CIDR block that defines that subnet. The OpCenter can start worker nodes in any subnet of the VPC. Each worker is assigned a private IP address from the /20 CIDR block that defines the subnet in which the worker node is created.

Accessing the Default VPC

When created, the OpCenter, and all worker nodes, are assigned private IP addresses which are not reachable from the public Internet. There are several methods for enabling access from the public Internet, as described in the following examples.

  • Create all compute instances with public IP addresses as well as private IP addresses
  • Deploy a NAT gateway that translates between public IP addresses and private IP addresses
  • Deploy a VPN gateway that creates an encrypted tunnel over the public Internet to extend the VPC to the host you use to access the VPC

Limiting Access to Resources

Firewalls (called security groups in AWS) limit access to individual compute instances inside the VPC. Security groups have the following properties.

  • Apply separately to inbound and outbound traffic
  • Limit access to destination IP addresses from IP addresses (sources)
  • Limit access to TCP and UDP ports
  • Can be applied to, or removed from, a running EC2 instance
  • Rules comprising a firewall can be added, deleted, or modified while the firewall is in use

Designing a Security Policy

A comprehensive security policy applied to MMCloud covers many aspects including, for example, who is granted access and the composition of passwords. The security policy also covers which resources are accessible from the public Internet and how that access is enabled. Every organization has its own security policy. An example of a network architecture to support a security policy for an OpCenter deployment is shown schematically in the figure.

The figure shows that within the VPC all communication uses private IP addresses. All resources within the VPC have inbound firewall rules (or access control lists) to limit source addresses and the ports that are accessible. The green arrow indicates that some communication is allowed and the red arrow indicates that the remaining communication is not allowed.

In the example shown, only resources that support client connections are allowed inbound access from the public Internet. These resources are protected by inbound firewall rules that limit the source addresses of the clients that are allowed to connect.

Example of an MMCloud Security Architecture

MMCloud Security Architecture

Configuring a Security Policy

Warning

You must deploy MMCloud in accordance with your organization's security policy. If your organization does not have a security policy, you can use the suggestions in this section as a template.

  • Configure conservative firewall rules to limit access to the OpCenter and all worker nodes

    If you deploy the OpCenter from the AWS Marketplace, the CloudFormation template requires information that is used to create security groups for the OpCenter and all worker nodes that the OpCenter instantiates. Take a conservative approach: if needed, the security groups can be modified later using the AWS management console.

    The CloudFormation template prompts you for the following information.

    • 5mvPublicCIDR: The IPv4 CIDR block of source addresses that are allowed to access the OpCenter over the public Internet.

      Use the smallest IPv4 CIDR block that includes all computers that require access to the OpCenter. If it is a single computer, use the IPv4 address of that computer (/32).

    • 6mvSSHCIDR: The IPv4 CIDR block of source addresses that are allowed to connect via ssh.

      Access via ssh is not required to use the OpCenter although IT admins may prefer that ssh access is available to them. Users require ssh access to the Nextflow host to initiate Nextflow pipelines.

      Use the smallest IPv4 CIDR block that includes the IT admins and the Nextflow users.

    • 7mvInternalCIDR: The IPv4 CIDR block of source addresses that are allowed to communicate inside the VPC.

      Use the CIDR block of RFC 1918 addresses that define the VPC (for example, 172.31.0.0/16).

  • Allow public IP addresses for all worker nodes but limit access from the public Internet

    When you submit a job to the OpCenter, you can specify that the worker node must not have a public IP address. (If you use the cli, include the --noPublicIP flag with the float submit command. If you use the web interface, go to the Network tab and uncheck the Public IP address box.) If the worker node does not have a public IP address, the worker node cannot access any AWS services (unless you configure a gateway) and the job does not start.

    Firewall rules protect the worker nodes from inbound access by sources in the public Internet.

  • For any job where you must attach an inbound firewall to open a specific port, use the VPC CIDR block (for example, 172.31.0.0/16) as the range of allowed source IP addresses in the firewall rule

    Some jobs require that the worker node (host) publishes a port on the container so that clients can connect to a process running in the container. Examples are jobs running RStudio or Jupyter Notebooks. You must apply a firewall rule (security group) to allow access to the published port (for example, the default port for RStudio is 8787). Limit access to source IP addresses within the VPC.

    Note

    The gateway is a job that creates a reverse proxy that supports client connections over the public Internet. For the firewall rule applied to the gateway, allow source IP addresses from the smallest IPv4 CIDR block that includes the supported clients.

  • Change the admin password from the default the first time you log in to the OpCenter

  • Minimize the number of users who are the admin group
  • Do not submit jobs as the admin user
  • Wherever possible, use IAM roles, rather than root user credentials, to enable access to AWS services