Private Cloud's Deployment

Public clouds are designed for everyone but there are a lot of customers that need a private version of the cloud. Sometimes, they need physically isolated data centers and networks located in their own country. These private clouds offer Platform-as-a-Service (PaaS), Infrastructure-as-a-Service (IaaS), and Software-as-a-Service (SaaS) service models just like other data centers. Some features on public cloud offerings might be delayed released in a private cloud as compliance and security complicate deployment.

As the race for private government clouds is heating up, governments are becoming more strict about their citizens' data. More and more private clouds are coming up. Some of the popular offerings in this area include Azure China, Azure Germany, Azure for US Government, AWS Germany, AWS China, Google for Government, and the list goes on. Compliance, data privacy, and security restrictions for these clouds apply not only to cloud customers but also to cloud providers. For instance, Azure developers would have to go through compliance requirements before their change is deployed in a private cloud. 

Typically, for restricted clouds to manage compliance, data privacy, and security restrictions, a third-party provider is required to manage deployments and maintenance for that cloud. Usually, ingress to these private clouds is allowed while egress is limited. There are a lot of options available for users of public clouds, but for private clouds, there is no readily available solution. Service providers have either in-house custom solutions or they have some cleared personnel who can log in and manually deployments to private clouds. For large service providers, there are hundreds of teams that need to perform thousands of releases into these private clouds on a daily basis. So, cloud operators executing deployment scripts and returning the result back to the developer won't scale for large service providers. Imagine each deployment for AWS service going through a cloud operator. Also, you can't have CI/CD deployment to these clouds because the provider needs control release to their private cloud at any point. They should have the capability to stop releases. Additionally, they need the capability to audit the deployments happening, as data should not leave their cloud. In this article, we will be discussing the possible architecture of these private cloud deployments. 

Architecture

At a high level (Figure 1), the developers on the public cloud can create a release request with all the release metadata and parameters. Pass the release request to the private cloud deployment service, and the private cloud deployment service will take care of deployment to the private cloud.

Private Cloud Deployment Service

Let's look at the different components in this system as shown in Figure 2:

• Public Deployment Service (PDS): This service can take release metadata and release parameters and orchestrate release compliance requirement execution.
• Public Compliance Manager (PCM): This service takes permission from the private cloud and makes sure of all public compliance requirements with the help of RCV. Sign the release request and request PCCM for private cloud-specific compliance.
• Release Compliance Validator (RCV): This service validates that the compliance requirements are adhered to, like Federal Risk and Authorization Management Program (FedRAMP), International Traffic in Arms Regulations (ITAR), Criminal Justice Information System(CJIS)  guidelines for the US government.  
• Private Cloud Compliance Manager (PCCM): Private cloud compliance manager receives requests from PCM. PCCM validates, approves, and creates release audit records with the help of RCV and sends a response back to PPM.
• Private Release Compliance Validator (PRCV): This service is similar to RCV but validates compliance rules for private clouds.
• Private Cloud Deployer (PCD): Manages the deployment in private clouds and returns only success/failure message to the Public Deployment Service (PDS).
• Cloud Resource Deploy (CRD): Cloud resource that is actually being deployed.

Private cloud deployment service will have the above micro services deployed to multiple clouds. Public Deployment Service (PDS) receives requests in the form of release metadata and release parameters. Now, before we kick off the release in the private cloud, we need to ask permission from the private cloud. For this purpose, the Public Compliance Manager (PCM) establishes a bidirectional connection with its counterpart component, the Private Cloud Compliance Manager (PCCM). 

PCM will create a release request, sign it with its own private key, and send it to PCCM. PCCM will verify PCM signatures, ask the Release Compliance Validator (RCV) to validate the release request, and then request approval from private cloud admins. 

Once the release is approved, PCCM creates a signed record with its own signature and sends it to PCM. PCM and PCCM will both maintain their own private audit record with signatures from both parties. 

PCS will send all the release configurations and release metadata to the Private Cloud Deployer (PCD). Before triggering the release, PCD needs to confirm with PCAM that a particular release is approved for release on their private cloud and receives deployment credentials for private cloud deployment. Once confirmed, deployment will start in the private cloud, and only success/fail messages will be sent back to the public cloud to protect data privacy rules on the private cloud. 

PRCV and RCV can be the same code deployed with different configurations; the same applies to PCM and PPCM as, fundamentally, they are similar microservices with different configurations. Private cloud deployment service thus eliminates the need for Private Cloud operators to deploy service by establishing a secure connection with the public cloud and still taking control of deployments and their data.  

Conclusion

In this article, we have provided one of the architectures for deployment to private clouds. This article talks about a very high-level view of the system. Details like IPC, hosting platform, storage systems, and database systems are intentionally omitted from this article as depending on your cloud provider, you might have different options, and the selection of one over the other doesn’t affect the overall operation of the system. This architecture can help with deployments to private trusted clouds for different IaaS, PaaS, and SaaS providers. Our solution does provide high security, compliance checks, hooks, and auditing with the signatures of both parties. This architecture can be applied to several classes of problems where we have software producers and software consumers as two different organizations, and there is semi-trust between them.