This topic explains defining deployments and defining applications in CloudSecure. Additionally, it explains why you may want to define deployments to segment your applications. Note that although deployments are recommended, they are optional.
To further explain these concepts, the topic includes an example of how to define an application and the three deployments hosting it.
What is a Deployment in CloudSecure?
In CloudSecure, you may decide to create deployment stacks as part of specifying which applications in your cloud account to protect with CloudSecure.
After onboarding your cloud accounts, you may begin by defining the environments you're using in the cloud. In CloudSecure, we refer to this as “adding deployment stacks.” In the cloud, stacks provide a way to manage your resources as a single, atomic unit.
In CloudSecure, a deployment stack correlates with the stages that organizations use to manage their product development lifecycle and defines the boundaries of application deployment. To define these boundaries in CloudSecure, you create your deployment stacks by selecting an Environment label. Then, associate that Environment label with cloud metadata (such as tags), and resources to define the boundaries of that environment.
For example, you might realize that you want a deployment stack in CloudSecure equal to your development environment that exists for your AWS us-west-1 region. Perhaps, this environment is constrained to operate only on a specific subnet. Typical environments include development, staging, and production.
Relationship between Deployments and Applications
To more fully use CloudSecure, you need to understand the relationship between applications and their deployments.
In CloudSecure, you will typically work with two special label types to manage security for your cloud resources. These label types are also related to deployments as defined above. As explained above, deployment stacks use an Environment label. You associate attributes to that label to set the boundaries of the stack. Recall that deployment stacks are optional but often helpful.
Defining an application follows a similar process. You begin by specifying an Application label. Then, you associate cloud resources to that label by selecting the appropriate cloud tags or cloud metadata associated with that application.
Ultimately, the process of getting the most out of your application definition involves:
-
(Optional) First, defining your deployment stacks
You only need to define deployment stacks first if:
-
You wish to define your application with deployment stacks (that is to say define them in part by environment and environment-specific resources)
-
You haven't previously defined any. If you've already defined your deployment stacks, simply select them when defining your applications.
-
- (Optional) Second, creating tag to label mappings. See Cloud Tag to Label Mapping for information.
CloudSecure analyzes each of these types of definitions and sees the unions between them. For example, it's able to detect that the CRM application you defined is hosted in the Staging and Production deployments running in your Azure and AWS clouds, respectively.
CloudSecure gets you started by including Environment labels for Production, Staging, and Development in its deployment definitions page.
Organizations also create their own environment-specific definitions around how they have deployed applications; for example, they might have an environment for Eastern European Engineering.
To break these concepts down further, see how CloudSecure utilizes Application and Environment labels.
Application Labels
You define an application using cloud tags and/or cloud metadata so that CloudSecure can discover the deployments and resources for that application.
For example, you have two applications — a Payment application and a CRM application. In CloudSecure, you define each application and assign them an Application label.
Environment Labels
Your company has different deployments of your applications. You can think of these environments as different instances of each application based on where they reside. For example, your company has a staging environment and a production environment.
In the illustration above, your Payments and CRM applications reside in two environments — production and staging. These two applications are “deployed” in both production and staging. In this way, you assign these applications to the correct deployments.
CloudSecure Discovers Your Application Environments
When you define a deployment, CloudSecure doesn't discover anything about your applications. You defined your deployment stacks separately. Then, after you defined each application, CloudSecure analyzes them by reviewing the associated cloud metadata, such as account, VPC, subnet, tags, etc. CloudSecure recognizes the union of those separate definitions and determines the environments where your applications are running, if you have defined deployments. This union defines each application's environment boundary.
Say you create an application definition (CRM in this example) and save it. CloudSecure begins the process of discovering the environments in which it's running and the resources that it has. The Application Definitions page refreshes to include the new application definition, and the Details page for that application definition displays the message "DISCOVERY STATUS: QUEUED."
After discovering all the associated environments and resources, the Details page for that application definition displays the message "DISCOVERY STATUS: COMPLETE," and the Application Definitions page lists all the discovered deployments and resources matching your selected cloud metadata. If it discovers, deployments or resources, the approval status will show as pending.
CloudSecure will not populate the Deployments & Resources column if none are discovered or if existing application definitions already feature the ones you selected for your new application definition.
Why is Environment Discovery Important?
CloudSecure treats each environment where an application runs as a separate application instance. This functionality allows you to define policy tailored for the environment.
For example, you might want very flexible and open security policy for applications running in your Development environment. However, when those applications move to production, you may require very controlled policy to eliminate risk.
Example Deployment and Application Definitions
In this example, a company has the standard development, staging, and production environments. It manages a travel ticketing application on its corporate website. The company uses both Amazon AWS and Microsoft Azure to host this application and its environments.
In AWS, the company's “Corp” account has a VPC that they use as their staging environment (the “VPC Staging”) and a VPC they use for their development environment (the “VPC Eng”). Their “Finance” account in Azure has a resource group that they use for their production environment.
The travel ticketing application has resources in both the AWS and Azure accounts and in all three environments. It uses two resources in the AWS Staging VPC and a database in the AWS VPC Eng. They host their production environment in their Azure Resource Group, and use these resources: a load balancer, two VMs, and a storage account.
In CloudSecure, the company defines the resources that are part of this application.
They begin by defining all three deployments— development, staging, and production. See Define a Deployment. Then, they are ready to define the application in CloudSecure. When they define the application, they specify the scope for what comprises the application. See Define an Application Automatically and Define an Application Individually.
In the application definition, they specify cloud tags and metadata as follows:
- The AWS Corporate account → US East 1 region → 2 VPC s - Staging and Engineering → Subnets 1 and 2
- The Azure Finance account → APAC VNet → Subnets A and B and a storage blob
They have already defined their environments: the development and staging environments in AWS and their production environment in Azure. CloudSecure can now determine that the application has resources in the AWS development and staging environments and resources in the Azure production environment.
In CloudSecure, the travel ticketing application appears as three separate instances and each instance can have its own security policy.