Set up your organization

When you first onboard to Trusted Cloud, you are provided with a new empty organization. To use this organization, you need to configure it with projects, a network, and other resources. Trusted Cloud provides multiple options for configuring your organization, including Terraform modules that help you quickly set up the resources you and your users need to get started.

This page is for administrators who need to configure a new organization in Trusted Cloud.

Before you read this guide, you should:

Before you begin

Ensure the following for all setup options:

We also strongly recommend that you review the Trusted Cloud by S3NS Setup guided flow before going through a full enterprise configuration. While not all sections are relevant to Trusted Cloud (for example, you can't create an organization yourself), it provides useful background information, guidance, and best practices for setting up your infrastructure. The same best practices are reflected in our provided Terraform modules. Be aware when going through the guided flow that enterprise configuration from the Trusted Cloud console is not available in Trusted Cloud.

Configuration options

There are three possible options for setting up an enterprise organization on Trusted Cloud:

  • (Recommended) Use our provided Terraform modules to set up your organization. This is an adapted version of Google Cloud's Cloud foundation configuration, which follows best practices for setting up an enterprise-ready organization.
  • (Advanced users only) If you have existing Terraform "landing zone" modules that you have used in Google Cloud, you can adapt and reuse them to configure your organization in Trusted Cloud. If you choose this option, you should carefully review the differences between the two universes, both at a high level and for any services you want to use.
  • You can manually create projects, networks, policies, and other resources by using the Google Cloud CLI or the Trusted Cloud console, following the instructions in the relevant documentation. You can use this approach for a minimal configuration as described in the next section or a full enterprise setup, using our suggested configuration or your own preferred version.

Minimal configuration

If you just want to try out your new organization before setting it up fully, you can add a single project and Virtual Private Cloud (VPC) network. This basic deployment is enough to explore available services and run our quickstart tutorials:

  1. Create a project in your organization.

  2. Create and configure a VPC network called default in your project with the following commands:

    gcloud compute networks create default
gcloud compute firewall-rules create default-allow-internal --allow=tcp:1-65535,udp:1-65535,icmp --source-ranges 10.128.0.0/9
gcloud compute firewall-rules create default-allow-ssh --allow=tcp:22
gcloud compute firewall-rules create default-allow-rdp --allow=tcp:3389
gcloud compute firewall-rules create default-allow-icmp --allow=icmp

No default network

If you're familiar with Google Cloud, you might not expect to have to create a network: in Google Cloud, a default VPC network (with pre-populated IPV4 firewall rules) is created automatically for each project. A Trusted Cloud project, however, does not have a default network, so you need to create one yourself for you and your team members to get started.

Suggested configuration

The following is the configuration that's deployed with our provided Terraform, which is an adapted version of Google Cloud's Cloud foundation configuration. You can also use this section as a guideline if you choose to manually create your own resources and policies with the Trusted Cloud console or Google Cloud CLI.

While this configuration represents many best practices that we have found work for most organizations, it might not meet all your organizational or technical requirements. Review this section (and the Terraform itself if using) carefully, and customize the configuration if required.

The following sections describe the various resources in our suggested configuration.

Organization

At the top level of your organization, our suggested configuration has two folders. The first folder contains projects that contain common resources such as Cloud KMS and Logging resources shared by your organization. The other folder is used to store network-related projects such as the Cloud DNS hub for your organization, and base and restricted network Shared VPC host projects for each environment (development, non-production, and production).

example-organization
└── fldr-common
    ├── s3ns:prj-c-kms
    ├── s3ns:prj-c-logging
└── fldr-network
    ├── s3ns:prj-net-dns
    ├── s3ns:prj-d-shared-base
    ├── s3ns:prj-d-shared-restricted
    ├── s3ns:prj-n-shared-base
    ├── s3ns:prj-n-shared-restricted
    ├── s3ns:prj-p-shared-base
    └── s3ns:prj-p-shared-restricted

Environments

Our suggested configuration has a folder for each environment: production, non-production, and staging. Each folder contains a project that can be used by Cloud KMS for key management resources associated specifically with this environment.

example-organization
└── fldr-development
    ├── s3ns:prj-d-kms
└── fldr-nonproduction
    ├── s3ns:prj-n-kms
└── fldr-production
    ├── s3ns:prj-p-kms

Network topology

The configuration has a Shared VPC network per environment (development, nonproduction, and production) in a standard configuration with a reasonable security baseline. This configuration includes:

  • (Optional) Example subnets for development, nonproduction, and production inclusive of secondary ranges.
  • Hierarchical firewall policy created to allow remote access to VMs.
  • Hierarchical firewall policy created to allow for load balancing health checks.
  • Hierarchical firewall policy created to allow Windows KMS activation.
  • VM / encrypted disk
  • Default Cloud DNS policy applied, with DNS logging and inbound query forwarding turned on.

Projects

Each environment can have a number of service projects connected to the Shared VPC networks described in the previous section. If you deploy it unmodified, our provided Terraform creates the following set of projects. The projects are grouped in folders in each environment, where each folder is associated with a particular business unit. For each business unit, a shared infra-pipeline project is created with Cloud Build triggers, Certificate Signing Requests (CSRs) for application infrastructure code and Cloud Storage buckets for state storage.

example-organization/
└── fldr-development
    └── fldr-development-bu1
        ├── s3ns:prj-d-bu1-sample-floating
        ├── s3ns:prj-d-bu1-sample-base
        ├── s3ns:prj-d-bu1-sample-restrict
        ├── s3ns:prj-d-bu1-sample-peering
    └── fldr-development-bu2
        ├── s3ns:prj-d-bu2-sample-floating
        ├── s3ns:prj-d-bu2-sample-base
        ├── s3ns:prj-d-bu2-sample-restrict
        └── s3ns:prj-d-bu2-sample-peering
└── fldr-nonproduction
    └── fldr-nonproduction-bu1
        ├── s3ns:prj-n-bu1-sample-floating
        ├── s3ns:prj-n-bu1-sample-base
        ├── s3ns:prj-n-bu1-sample-restrict
        ├── s3ns:prj-n-bu1-sample-peering
    └── fldr-nonproduction-bu2
        ├── s3ns:prj-n-bu2-sample-floating
        ├── s3ns:prj-n-bu2-sample-base
        ├── s3ns:prj-n-bu2-sample-restrict
        └── s3ns:prj-n-bu2-sample-peering
└── fldr-production
    └── fldr-production-bu1
        ├── s3ns:prj-p-bu1-sample-floating
        ├── s3ns:prj-p-bu1-sample-base
        ├── s3ns:prj-p-bu1-sample-restrict
        ├── s3ns:prj-p-bu1-sample-peering
    └── fldr-production-bu2
        ├── s3ns:prj-p-bu2-sample-floating
        ├── s3ns:prj-p-bu2-sample-base
        ├── s3ns:prj-p-bu2-sample-restrict
        └── s3ns:prj-p-bu2-sample-peering
└── fldr-common
    ├── s3ns:prj-c-bu1-infra-pipeline
    └── s3ns:prj-c-bu2-infra-pipeline

Logging and monitoring

The last step in our suggested configuration configures a log bucket and Pub/Sub log sink in the organization's common logging project. The required APIs are enabled as necessary. A non-intercepting aggregated sink is configured at the organization level to route log entries to the common project that contains the log bucket. You can learn more about how this works in Centralized log storage.

Your and your organization members can view logs in the Logs Explorer from the Trusted Cloud console or by connecting a subscription to the Pub/Sub topic in pull mode. Cloud Logging in Trusted Cloud retains logs for thirty days only.

Use Terraform to configure your organization

Our recommended approach to configure your organization is to use Terraform, particularly if you have never set up an organization on Google Cloud. The provided Terraform automatically sets up default folders, projects, centralized logging and monitoring, networking, and more, as described in Suggested configuration. You can adapt this configuration to your own needs either before or after deployment.

The Terraform is adapted from Google Cloud's Cloud foundation configuration. You can find out much more about the Cloud foundation modules in its repository, though be aware that not all the information is relevant to this Trusted Cloud-specific setup.

Before you start, ensure that you have the Terraform tool installed. Because Cloud Shell is not supported in Trusted Cloud, follow the instructions to install Terraform locally.

Download the Terraform files.

To download the latest Terraform assets, contact your support or account team. Public Terraform download from GitHub is coming soon!

Before deploying the configuration, review (and if required, edit) what's deployed for your organization, as described in Suggested configuration. In addition to the configuration, the provided Terraform also includes a bootstrap module that deploys the following:

  • A s3ns:prj-b-seed project that contains the following:
    • Terraform state bucket
    • Custom service accounts used by Terraform to create new resources in Trusted Cloud

Apply the Terraform

To apply the Terraform, do the following:

  1. Go to the directory that contains the Terraform configuration files.

  2. Open and edit the provided terraform.tfvars file to specify your chosen values for the following parameters:

    org_id = ORG_ID
billing_account = BILLING_ACCOUNT
billing_project = moonrise-replacea3e60e43996f40c28fe304bb52b4efbemoonrise-replace:BILLING_PROJECT
prefix = FOLDER_PREFIX

    Replace the following:

    • ORG_ID: Your organization's unique ID
    • BILLING_ACCOUNT: Your billing account
    • BILLING_PROJECT: Your organization's billing project (sometimes known as its quota project)
    • FOLDER_PREFIX (optional): A prefix you want to apply to all unique folder and project names

  3. Deploy the configuration.

    terraform init
terraform apply

Troubleshoot deploying Terraform with existing resources

If the downloaded Terraform configuration attempts to create resources that already exist, Terraform exits with a 409 error code. To resolve these errors, you can delete the resource by using the Trusted Cloud console or gcloud CLI, and then re-apply the Terraform configuration. Alternatively, if these resources are critical and cannot be deleted, you can import resources into your Terraform state.

Verify your setup

To verify your setup, we recommend that you first check by using the Google Cloud CLI or the Trusted Cloud console that your folder and project structure have been set up correctly.

You can then try deploying an application workload or workloads in one of the service projects, either using a workload of your choice or by following some of our quickstart tutorials. These are short tutorials that help you quickly get a simple example up and running on Trusted Cloud. Find out more in What's next.

What's next