# Deployment Zones

# Overview

When an Application is run, it executes in a specific Deployment Zone. A Deployment Zone represents a network environment within a specific GCP or AWS project.

By default, CloudWright provides customers with a managed Deployment Zone, which is isolated from other customers. This default zone is a fully-supported environment — customers should feel comfortable publishing production applications into the CloudWright-managed zone.

In some cases however, network, security, or legal restrictions may require customers to execute Applications in a self-hosted cloud environment. To support these use cases, CloudWright allows customers to provision and deploy Applications into self-hosted Deployment Zones — that is to say, into networks in their own cloud environment.

This section describes the architecture differences between managed and self-hosted Deployment Zones, and describes the process of provisioning a self-hosted zone.

# CloudWright Managed

Every CloudWright install is provisioned with a default 'CloudWright Managed' deployment zone, in a cloud project managed by CloudWright. Resources in this environment are secure and isolated from other customers.

Because the CloudWright Managed zone is not connected to customer clouds or networks, any Module which connects to customer-internal resources (APIs, databases, etc) from the managed zone must connect over the internet. An example customer architecture would look like this:

Managed Architecture

From a security perspective, there are two important considerations when using this architecture:

  • The RDS instance must be externally reachable, via hostname or IP address
  • To access S3, the CloudWright module must be given credentials to a service user with access to the S3 bucket(s) in question.

Publishing to the CloudWright managed zone is the simplest way for users to start building applications. However, if customers are unable to use this model for legal or contractual reasons, CloudWright also allows customers to create self-managed Deployment Zones.

# Customer Managed

In some instances, a customer needs an Application to execute in their own cloud environment instead of the CloudWright-managed one. There are three main reasons a customer may need to publish Applications into a self-managed cloud environment:

  • The Application needs access to resources which are only available in certain network zones. For example, internal databases which have no external IP address, or whose ingress is limited by firewalls.

  • If a Module needs to access customer-managed cloud resources (for example, S3 buckets), access from the CloudWright-managed Deployment Zone must be granted via key-based authentication. For security reasons, some customers may require that resources are accessed only via role-based authentication.

  • Applications may process data which, for legal or contractual reasons, cannot leave the customer-controlled cloud environment.

To support these use-cases, CloudWright allows customers to provision self-hosted Deployment Zones and publish applications into those zones. The high-level architecture of a customer-managed Deployment Zone looks like this:

Self Managed Architecture

In this deployment model, CloudWright Applications are executed in a customer cloud — specifically, a GCP project or AWS account. These Applications may optionally be attached to a VPC network so they can directly access internal network resources.

The CloudWright management server will still be managed by CloudWright and live in a managed environment, but will authenticate as a service user when provisioning and running Applications.

# Creating a Customer-Managed Deployment Zone

Only users with 'System Administrator' permissions can to create new Deployment Zones. The Deployment Zone administration page can be reached by clicking the 'Admin' link in the left sidebar and selecting the 'Deployment Zones' tab.

Self Managed Architecture

The default 'CloudWright Managed' zone will be the only initial zone. Click 'New' to create a new zone.

Self Managed Architecture

After selecting a cloud provider and a name for your Deployment Zone, you will be presented with instructions for generating the accounts and resources that CloudWright needs in order to deploy infrastructure into your cloud. This guide describes at a high-level which accounts and resources will be needed; the Deployment Zone wizard gives details about why CloudWright needs each permission and resource.

Zone creation on different cloud providers will require different resources. Please carefully review the generated IAM commands to make sure you are comfortable granting the required permissions.

# Creating an Amazon Web Services Deployment Zone:

You will be presented with commands which create:

  • a 'function' role which your Applications will run as
  • an 'invoker' role used by CloudWatch crons to trigger your Applications
  • a service account user used to create Lambdas, SQS queues, and CloudWatch resources
  • an API Gateway instance used to serve HTTP endpoint triggers
  • an S3 bucket to hold publishable artifacts
  • a KMS key used to encrypt Module secrets

If you would like Applications in this Deployment Zone to attach to one or more VPC Networks, using one or more Security Groups, you will be prompted to provide them here. You can find more details about GCP VPC connectivity in the VPC Connections section

After creating these resources, you will be prompted to supply the AWS Access Key ID and Secret Access Key to let the CloudWright management server run as the admin service user.

# Creating a Google Cloud Platform Deployment Zone:

You will be presented with commands which create:

  • a 'function' service account which your Applications will run as
  • an 'invoker' service account used by Cloud Scheduler crons to trigger your Applications
  • an 'admin' service account used to create Cloud Functions, Pub/Sub queues, and to view logs
  • a GCS bucket used to hold publishable artifacts
  • a KMS keyring and key used to encrypt Module secrets

If you would like Applications in this Deployment Zone to use a VPC Connector connect to resources on a VPC network, you can provide the VPC connector ID here. You can find more details about GCP VPC connectivity in the VPC Connections section.

After creating these resources, you will be prompted to generate and upload a Service Acount Key to let the CloudWright management server use the admin service account.

# Module Authentication

Most CloudWright Modules connect Applications to external resources like APIs, databases, or cloud services. To connect to these resources, Modules need to authenticate. Most of the time, Modules will authenticate using secrets — API keys, service account keys, or other account-specific credentials.

However, many cloud-native services on AWS and GCP allow role-based authentication. Under this model, permissions are granted to the role executing service calls, and applications access the resource without providing an explicit secret.

When a CloudWright Application runs, it executes as a scoped role. The role an application uses is determined by the Deployment Zone to which the application is published. For example, if a customer has created a customer-managed Deployment Zone an-aws-zone, new Applications can be published into this zone:

Compute Limits

The Deployment Zone creation wizard prompted the customer to create several roles (on GCP, service accounts). Applications will execute as the 'function' role. You can find the Application Resource Identifier for a Deployment Zone in the admin controls:

Compute Limits

  • On AWS, this will be a Role ARN, in the form of arn:aws:iam::131997619760:role/cloudwright/an-aws-zone/an-aws-zone-cloudwright-function

  • On GCP, this will be a Service Account ID, in the form of my-gcp-zone-cw-fn@myproject.iam.gserviceaccount.com

When role-based authentication is an option, CloudWright users can use this ID to grant permissions to Applications in a Deployment Zone without attaching secrets to the module. For example, if a customer wants to access their own AWS resources without providing security credentials, they can attach permissions to this role in their AWS IAM settings:

Compute Limits

Here, we have attached read-only S3 access to the role, but permissions could alternatively be scoped to specific resources. For a full explanation of AWS role-based authentication, please reference the AWS documentation. For a full explanation of GCP roles, please reference the GCP documentation.

Now, when creating an instance of the AWS API module, we can tell the module to use 'Role-Based' authentication. Since this module will only authenticate successfully in the an-aws-zone Deployment Zone, we can configure the 'Deployment Zone Restriction' so it can only be used by apps published to an-aws-zone:

Compute Limits

This module can now be attached to our Application and used to access S3 resources, the same as a key-authenticated module:

Compute Limits

# Usage Limits

Applications published to the CloudWright managed Deployment Zone are by default limited to 6 hours of compute time per day. This limit resets daily. Applications published to self-managed Deployment Zones do not have any compute time restrictions.

An Application's current compute time usage can be viewed on the configuration page, under the 'Monitoring' tab:

Compute Limits

If the Cloudwright-managed compute time limit is a problem for your team, please reach us at contact@cloudwright.io for more options.

# Permissions

# Team Restrictions

Admins can control which teams are allowed to deploy Applications into a Deployment Zone in the admin page:

Authorized Teams

By default, all CloudWright Teams will be allowed to use a Deployment Zone. If any Teams are specified here, only the ones listed will have access.

# Security Restrictions

Admins can disallow users from creating HTTP endpoints Triggers for their applications in the Deployment Zone admin page:

Security Restrictions

Note that this setting can only be toggled off when no existing Applications have HTTP Triggers.