Summary of Security Architecture for Deployment Environments

PubSub+ Cloud is highly available and secure as it leverages the PubSub+ event broker security practices for a SaaS service. By default, PubSub+ Cloud is designed for security in mind. In this section, we summarize the security architecture and the aspects of security that Solace manages and those that the customer must manage from the perspective of the deployment option chosen.

Before reading this page, consider reading the deployment architecture details to help you better understand the security architecture for which you (the customer) are responsible and which parts are the responsibility of Solace.

Security Architecture and Deployment Environments

The security architecture is described in terms of the deployment option and environment that the customer chooses. The deployment options can be broken down to ownership of an environment and its connectivity.

For details of the deployment options and connectivity, see PubSub+ Cloud Deployment Ownership Models and PubSub+ Cloud Deployment Connectivity Models where there are diagrams to help you better understand the deployment options. The following is a summary of the deployment ownership and connectivity options.

  • Control
    • The ownership model refers to the location of the region where the Mission Control Agent and software event brokers are installed. These are the variants of ownership:

      • Solace-Controlled Region: Dedicated event broker services are deployed in a Solace-controlled shared VPC/VNet on public cloud providers such as Amazon Web Services (AWS), Google Cloud Platform (GCP), Microsoft Azure.
      • Solace-Controlled, Customer-Dedicated Region: Dedicated event broker services are deployed in a Solace-controlled VPC/VNet dedicated to the customer on public cloud providers such as AWS, GCP, and Microsoft Azure.
      • Customer-Controlled Region: Dedicated event broker services are deployed in a customer's on-premises or cloud-based Kubernetes cluster, such as OpenShift, Rancher, Amazon (EKS), Azure (AKS, ARO), Google (GKE), Alibaba (ACK), Huawei (CCE), and more.
    • The ownership is an indication of who owns the responsibility for the security of the infrastructure and environment and is summarized as follows:
      • For Solace-controlled regions, it is secure by default for the customer because Solace manages security for the infrastructure. The customer and Solace collaborate to ensure connectivity requirements are satisfied.
      • For a customer-controlled region, the customer must manage the security for the infrastructure as well as the connectivity requirements.
  • Connectivity
    • The connectivity of a deployment refers to the way messaging clients access the event broker services. A messaging client can connect in three ways: via the public internet, via private IP addresses, or via a hybrid of both.

      • Public Internet: Messaging clients connect to the event broker service endpoints over the public internet.
      • Private IP Addresses: Messaging clients connect to the event broker service endpoints via private routes inside the customer's network.
      • Hybrid: Messaging clients in internal networks connect to PubSub+ Cloud via VPN. Messaging clients in the customer's cloud networks connect via network peering. Certain messaging applications may also be given access to PubSub+ Cloud via the public Internet.
    • Additional network configuration for dedicated regions are required for messaging clients to connect to the event broker services and the responsibility is related to the ownership model chosen as follows:
      • For Solace-controlled or customer-controlled environments, the access of client applications to the event broker service is managed by the customer if the clients reside in a private network. The customer is required to set up the connectivity from private IP addresses or hybrid configurations (e.g., permit external access to the Internet or configure VPC/VNet peering).
      • For Solace-controlled deployments, Solace works with the customer to ensure that the deployment matches the customer's connectivity requirements. For example, if the customer has client applications that reside in a private network (i.e., private IP addresses within a VPC/VNet), Solace exchanges route information with the customer to set up VPC/VNet peering or set up connectivity via site-to site VPN, AWS Direct Connect, or Transit Gateway.
      • For customer-controlled deployments, the customer manages the connectivity and takes care of setting up the necessary configuration (e.g., VPC/VNet peering, site-to-site VPN, AWS Direct Connect, Transit Gateway, loadbalancer, NAT configuration, etc.).

For more information about the security considerations, see Security Architecture for Solace-Controlled Regionsand Security Architecture Considerations for Customer-Controlled Regions, respectively.

Understanding the Security Architecture

All deployments that are supported permit for PubSub+ Cloud to meet different security requirements. There are a number of considerations, mostly related to ownership model of the resources, type of cloud solution chosen, and client connectivity.

For Solace-controlled regions, event broker service are installed in shared regions. For increased security, particularly if the customer wants their event broker services to be accessible only from a private network, the event broker services can deployed on an isolated VPC/VNet, which can be Solace-controlled or customer-controlled. For more information, see VPC/VNet Isolation.

Another factor to consider as part of the customer's security planning is how client applications connect. There are two types of client applications to consider as follows:

  • publishers and subscriber applications that use event broker services for messaging and passing data; these applications often connect from another VPC/VNet or from public infrastructure
  • optionally, the customer can create management applications that manage the life cycle of a event broker service; these applications are usually account -specific

For more information about connectivity, see Client Application Connectivity and Security.

As part of each deployment, a common set of components are used as shown in the following diagram:

To understand each of the components as they relate to security, see the following sections:

Summary of Security Architecture Considerations

Regardless of the environment that the customer chooses to deploy, each deployment has a well-defined architecture that share the same security considerations. The option you choose determines whether Solace or you (the customer) has the responsibilities for managing the deployment infrastructure.

The PubSub+ Cloud security architecture considerations can be summarized as follows:

  • Do the event broker services need to be publicly available from the Internet?

    • For publicly accessible event broker services, they can be deployed to a public cloud in a shared region. This is available in either a Solace-controlled region or customer-controlled region.
    • For non-public event broker services, recommends that deployments are made in a Kubernetes cluster within an isolated Virtual Private Cloud or Virtual Network (VPC/VNet). These type of deployments are available in a Solace-controlled, customer-dedicated region or a customer-controlled region.
  • What is the connectivity model used to access event broker services? 
    • The connectivity model that the customer chooses for client applications may influence the requirements to connect to the Solace Home Cloud and the central monitoring service. Connectivity to Home Cloud and the central monitoring service is a requirement for event broker services to function and are not optional. Either Solace-controlled or customer-controlled deployments that can be used.
    • Client applications are recommended to connect using VPC/VNet peering or loadbalancer solutions as described in the Solace deployment guides when using private IP addresses. It is possible to deploy event broker services in the same Kubernetes cluster alongside the client applications that use the event broker services. This configuration may be a preferred deployment option based on the customer's security requirements. This option is best in customer-controlled deployments.

For an understanding of the various deployment options and responsibilities, see the following sections:

Security Architecture for Solace-Controlled Regions

Environments that are Solace-controlled means that Solace controls and manages the infrastructure. Solace always uses the most recent security practices and either configuration is secure by default. The advantage when Solace controls the deployment is that the customer can focus on their event-driven architecture rather than managing the security aspects of their infrastructure. There are two different configuration options available:

  • Solace-controlled region, shared region — In this option, client applications access the event broker services over the public Internet and the infrastructure for a region is shared. For information about Solace-controlled region, see Security Architecture for Solace-Controlled, Shared Regions.
  • Solace-controlled, customer-dedicated region — In this option, usually event broker services are not publicly accessible from the Internet and the event broker services are run on a dedicated infrastructure for the customer. Client applications access the event broker service from another private network, which is customer-controlled. For more information, see Security Architecture for Solace-Controlled, Customer-Dedicated Regions.

Security Architecture for Solace-Controlled, Shared Regions

In this configuration, the event broker services that are deployed in a publicly accessible, shared region. This shared region is controlled and managed by Solace.

In this guide, we refer to Solace-controlled, shared regions as simply as Solace-controlled regions.

The event broker services are deployed to shared Kubernetes clusters per region (Google Cloud Platform) or shared VPCs/VNets per region (AWS or Azure), depending on the cloud provider chosen,.

The Solace-controlled region is best suited for environments where client applications access services from the public Internet. These can also include client applications from within a customer network, but in this situation, the customer must manage the access to applications from their own private network to the Internet.

In the following diagram, the red box shows the customer's security architecture responsibilities:

For a summary of the security responsibilities, see Customer Roles and Responsibilities for Security.

Security Architecture for Solace-Controlled, Customer-Dedicated Regions

For a Solace-controlled, customer-dedicated region, Solace ensures that the configuration of the Kubernetes cluster are secure and works with the customer to ensure that their client applications have connectivity.

This option is ideal when client applications do not access the event broker services from the public Internet and from a private network. It is also possible to configure this option to use a Hybrid connectivity model.

This option gives additional security option because the event broker services are deployed to a dedicated Kubernetes cluster within a dedicate region. The event broker services are not accessible from the public Internet - unless requested. Client applications can connect using VPC/VNet peering technology.

In the following diagram, the red box shows the customer's security architecture responsibilities:

For a summary of the security responsibilities, see Customer Roles and Responsibilities for Security.

Security Architecture Considerations for Customer-Controlled Regions

In customer-controlled regions, the customer deploys the event broker services to a dedicated private network, which the customer controls. A customer-controlled region gives the customer the most control over security, network configuration, and segregation to deploy event broker services and configure their infrastructure. The customer also controls the Kubernetes cluster (which can be either on-premises or in the cloud) and all aspects of the VPC/VNet where the Kubernetes cluster resides.

Solace recommends that event broker services are deployed to Kubernetes clusters whenever possible because of the inherent operational, flexibility, and security advantages. Kubernetes provides better fine-grained control and superior security compared to VM-based deployments. For more information, see Deploying PubSub+ Cloud with Kubernetes.

Though less commonly deployed, Solace does currently support deployments to VM-based environments on Amazon Web Services (AWS) and Azure. If the customer wants to use AWS or Azure, they should first consider using Amazon Elastic Kubernetes Service (EKS) or Azure Kubernetes Service (AKS), as alternatives. For more information, see Installing PubSub+ Cloud in Amazon Elastic Kubernetes Service (EKS) and Installing PubSub+ Cloud in Azure Kubernetes Service (AKS), respectively.

In summary, deployments of event broker services on customer-controlled infrastructure require that the customer considers the following as part of their security planning:

  • The requirements of the deployment type for the event broker services. Whether event broker services are deployed to a Kubernetes cluster (on-premises or in the cloud), or a VM-based deployment to a VPC/VNet, the deployment requires user accounts that are configured with the necessary, limited permissions. The customer may need to coordinate with their internal infrastructure and security teams to set up the user accounts.
  • The Mission Control Agent is provided with account permissions to manage event broker services in the customer's Kubernetes cluster. Solace recommends that a very limited set of permissions are assigned account for the Mission Control Agent to limit the risks and the vectors of attack. For more information about the Mission Control Agent, see Mission Control Agent.
  • Metrics and monitoring data is vital for the PubSub+ Cloud solution to work; it ensures that the event broker services are operating correctly. This system-level data identifies the event broker services so that Solace can properly monitor it as a SaaS. Solace doesn't and cannot access the contents of the messages (data) transported on the customer's network. For PubSub+ Cloud to function correctly, the customer must permit outgoing monitoring traffic from their VPC/VNet.

These deployments mean that the customers control and manage all aspects of the deployment, connectivity, and security.

For considerations about Kubernetes-based deployments, see Security Architecture for Customer-Controlled Regions .

For considerations about VM-based deployments, see Security Architecture for Customer-Controlled Regions (VM-Based).

Security Architecture for Customer-Controlled Regions

For customer-controlled regions, Kubernetes clusters (on-premises or in the cloud) offer a number of deployment variations that include:

  • On premises:
    • OpenShift
    • Rancher
    • VMWare Tanzu
  • In the cloud:
    • Amazon Elastic Kubernetes Service (EKS)
    • Azure Kubernetes Service (AKS)
    • Azure Red Hat OpenShift (ARO)
    • Google Kubernetes Engine (GKE)
    • Alibaba Cloud Container Service for Kubernetes (ACK)
    • Huawei Cloud Container Engine (CCE)

In the case where the deployment occurs to Kubernetes, the customer controls the management of the resources, configuring the networking, and overall security of the Kubernetes cluster. The customer can coordinate with Solace to deploy PubSub+ Cloud.

Prior to working with Solace, the security and permissions in the customer's environment can be defined and completed in the Kubernetes cluster deployment before the installing PubSub+ Cloud.

In the following diagram, the red box shows the customer's security architecture responsibilities:

For a summary of the security responsibilities, see Customer Roles and Responsibilities for Security.

Security Architecture for Customer-Controlled Regions (VM-Based)

Deploying event broker services directly to a customer-controlled region using a VM-based approach is supported, but is not the recommended architecture to use. Solace recommends that deployments are Kubernetes-based for their advantages in security. If the customer needs to use AWS or Azure, they should consider using Amazon Elastic Kubernetes Service (EKS) or Azure Kubernetes Service (AKS), respectively.

For VM-based deployments on customer-controlled regions, the customer is responsible for the resources, setting up the networking, and managing the security for their network.

This includes initial deployment and upgrades of the Mission Control Agent to the same VPC/VNet where the event broker services are deployed. These considerations are specific to deployments on cloud providers such as Azure, Amazon Web Services (AWS), Huawei, and Alibaba Cloud.

In the following diagram, the red box shows the customer's security architecture responsibilities:

For a summary of the security responsibilities, see Customer Roles and Responsibilities for Security.