Apply for invite to IaCP

Input Policy

Overview

The Scalr policy engine is a library of pre-built policies specifically created to restrict Terraform variable choices in the template registry. The template registry is the only use case where these types of policies can be applied, Open Policy Agent (OPA) policies can be applied during a Terraform run. A Terraform template and Scalr policies are linked together with a scalr-module.hcl file and applied only when the policy is created and the Terraform template is imported into the template registry.

The policy engine is part of the account scope, thus enabling business units to implement consistent governance policies across all of their cloud environments.

../_images/policy_menu.png

There are three steps to defining and enabling policies in the Scalr UI:

  1. Create a policy group.

  2. Add policies and policy conditions to the policy group.

  3. Attach the policy group to the required environments.

Policy conditions provide fine grained control over the application of a policy, allowing for policy variations across different clouds, locations, accounts and more.

Creating Scalr Policy

Policies are defined by clicking on:

  1. Policy engine

  2. Policy groups

  3. New policy group which will display this screen:

    ../_images/policy_group.png

Policy groups require a name and type. The type determines the options available for policy rules and includes types related to all clouds and cloud specific types. Cloud specific types will only appear in the drop down if there are cloud credentials configured for that cloud at either the Scalr scope or in the currently active Account. For IaCP environments, the following input policies are allowed:

  • AWS

  • Azure

  • Google Compute Engine

The policy reference below explains the policy types and their associated rules.

Attaching Policy Groups to Environments

Policy groups will only take effect when they are attached to environments. You can only attach one input policy group of each type to an environment.

  1. Click on environments in the bookmarks bar or main menu and select the environment you wish to attach policy groups to.

    ../_images/link1.png
  2. Click on “attach policy groups”on the right-hand side, attach the required policy groups to the environment, and save.

    ../_images/link_2.png

Using Global Variable in Policies

Global variables in policies make it possible to vary the details of the policy at any level where global variables can be set. A good example of this is a policy that enforces tagging on resources. The cloud.tags policy is available for all cloud types and provides a list of tags that must be applied to resources ordered from the template registry in the environment the policy applies to.

../_images/gv_tag_policy.png

By using a global variable name (in this example. {MyGlobalVariable}) rather than an actual value, the value applied to the tag will be determined from the global variable at the time the template is launched, based on the value of the variable at that time.

Scalr Policy Engine Compatibility with Terraform

Scalr policies are out of the box policies used to restrict the Terraform variable selection in the template registry. For example, Terraform templates deployed through the template registry in a specific environment can only build in AWS us-east-1 or us-west-1. Unlike Open Policy Agent (OPA), these policies are enforced upfront and only in the template registry use case.

../_images/built-in_example.png

Scalr policies tie together with Terraform templates with three components:

  • variables.tf - Where the Terraform variable is defined.

  • scalr-module.hcl - Where the Terraform variable is linked to the Scalr policy.

  • Scalr Policy Engine - Where the actual Scalr policy is created and applied to an environment.

Let’s walk through a simple example to give you a better idea of how everything is linked together:

  1. Create a S3 template:

provider "aws" {
 region     = var.region
}
resource "aws_s3_bucket" "scalr" {
 bucket = var.bucket_name
 acl    = "private"
}
  1. In the template, we have created a variable for region and want the end user to input the region value in the template registry. To make it a required input in the template registry, leave the variable default value blank in the variables.tf:

variable "region" {}
variable "bucket_name" {}
  1. Create a scalr-module.hcl to link the Terraform variable to the Scalr policy:

version = "v1"
variable "region" {
 policy = "cloud.locations"
 conditions = {
 cloud = "ec2"
 }
}
  1. Now that the three files have been created, you just need to create the policy in the Scalr UI and attach it to an environment. Navigate to the account scope:

    ../_images/account_scope.png
  2. Go to the policy engine:

    ../_images/policy_engine.png
  3. Click on “new policy group” and select “AWS” as the type:

    ../_images/new_group_aws.png
  4. Create a policy for cloud.locations and select the regions that are allowed and click ok:

    ../_images/cloud.location.png
  5. Now that the policy is created, attach it to the environment by clicking on environments, policies, then click on “attach policy groups”” on the right and save:

    ../_images/link1.png

Now all AWS Terraform templates that are deployed through the template registry in that environment will be restricted to the region(s) you have selected, if the scalr-module.hcl exists.

For a full end to end example of setting up a template registry with policy, please click here: Guide : Self service with Terraform

Policy Reference

Below is a list of possible cloud types with their aliases in the Scalr policy Engine.

  • ec2 - Amazon Web Services

  • gce - Google Cloud Platform

  • azure - Microsoft Azure

  • vmare - VMWare

All cloud-dependent policies require “cloud” conditions as seen below or in the example above.

Below is a list of the policy types which are supported by each cloud. The only differences are in conditions, where you have to specify cloud-dependent values (e.g., cloud, cloud.location, etc.).

Common Policies

Policy

Condition

Required

Condition value

Supported TF Variable types

cloud.instance.name.template (Sets a naming convention for instance names)

cloud.location

No

Cloud location identifier

string

os.type

No

One of: [linux, windows]

cloud.instance.types (Restricts instance types that can be used)

cloud.location

No

Cloud location identifier

string

os.type

No

One of: [linux, windows]

cloud.locations (Restricts locations that can be used on a cloud)

string

cloud.networks (Restricts networks (VPCs, VLANs) that can be used)

cloud.location

ec2, openstack, otc, rackspacengus - yes, azure, gce - absent

Cloud location identifier

string, list

cloud.storage.maximum_size (Sets a maximum size for storage in GB)

cloud.location

No

Cloud location identifier

number

cloud.subnets (Restricts subnets that can be used inside networks)

cloud.location

Yes

Cloud location identifier

string, list

cloud.network

Yes

Network identifier

resource.group (for azure only)

Yes

Resource group identifier

cloud.tags (Sets list of tags that will be applied to resources)

cloud.location

No

Cloud location identifier

map

os.type

No

One of: [linux, windows]

scalr-module.hcl example for a common policy type:

version = "v1"

variable "region" {
  policy = "cloud.locations"
  conditions = {
  cloud = "ec2"
  }
}

variable "vpc_id" {
  policy = "cloud.networks"
  conditions = {
    cloud = "ec2"
    cloud.location = "${var.region}"
  }
}

Amazon Web Services

Policy

Condition

Required

Condition value

Supported TF Variable types

aws.iam.instance_profiles (Restricts IAM instance profiles that can be applied to instances)

string, list

aws.iam.roles (Restricts IAM Roles that can be used)

cloud.location

Yes

string, list

cloud.service

Yes

One of: [emr, lambda, applicationAutoScaling]

aws.kms.keys (Restricts KMS keys available for storage encryption)

cloud.location

Yes

AWS cloud location identifier

string, list

cloud.service

No

One of: [ec2, rds, efs, lamda]

aws.rds.instance_types (Restricts Instance Types that can be used by RDS)

cloud.location

No

AWS cloud location identifier

string, list

aws.rds.db_engine

No

One of: [mysql, oracle-se, oracle-se1, oracle-se2, sqlserver-ee, sqlserver-se, sqlserver-ex, sqlserver-web, postgres, aurora, aurora-postgresql, mariadb]

cloud.resource.name.prefix (Sets a prefix for cloud resource names)

cloud.service

Yes

One of: [elb, rds, s3]

string

cloud.location

No

AWS cloud location identifier

cloud.security_groups (Sets or Restricts Security Groups that can be used)

cloud.location

No (Required with cloud.network)

AWS cloud location identifier

string, list

cloud.network

No

VPC identifier

cloud.service

No

One of: [ec2, rds, elb, alb, efs, lamda]

os.type

No

One of: [linux, windows]

cloud.storage.volume_types (Restricts volume types that can be used)

cloud.location

No

AWS cloud location identifier

string, list

scalr-module.hcl example for an AWS policy type:

version = "v1"

variable "region" {
 policy = "cloud.locations"
  conditions = {
   cloud = "ec2"
 }
}

variable "vpc_id" {
 policy = "cloud.networks"
  conditions = {
    cloud = "ec2"
    cloud.location = "${var.region}"
}
}

variable "subnet" {
 policy = "cloud.subnets"
  conditions = {
   cloud = "ec2",
    cloud.location = "${var.region}",
    cloud.network = "${var.vpc_id}"
 }
}

Microsoft Azure

Policy

Condition

Required

Condition value

Supported TF Variable types

azure.availability_sets (Restricts Availability Sets that can be used)

resource.group

Yes

Resource group identifier

string, list

azure.resource_groups (Restricts Resource Groups that can be used)

cloud.location

No

Region identifier

string, list

cloud.service

No

One of: [compute, network]

azure.storage_accounts (Restricts Storage Accounts that can be used)

string, list

cloud.security_groups (Sets or Restricts Security Groups that can be used)

cloud.location

No

Region identifier

string, list

cloud.network

No

Network identifier

resource.group

No (Yes if cloud.network specified)

Resource group identifier

scalr-module.hcl example for Azure:

version = "v1"

variable "region" {
  policy = "cloud.locations"
  conditions = {
  cloud = "azure"
  }
}

variable "resourcegroup" {
  policy = "azure.resource_groups"
  conditions = {
  cloud = "azure"
  }
}

Google Cloud Platform

Policy

Condition

Required

Condition value

Supported TF Variable types

gce.custom_instance_type.maximum_ram (Sets a maximum size for custom instance types in GB)

cloud.location

No

GCP region identifier

number

gce.custom_instance_type.maximum_vcpus (Sets a maximum number of VCPUs for custom instance types)

cloud.location

No

GCP region identifier

number

gce.network_tags (Sets or Restricts Network Tags that can be used)

cloud.location

No

GCP region identifier

list

gce.service_accounts (Restricts service accounts that can be applied to instances)

string, list

VMWare

Policy

Condition

Required

Condition value

Supported TF Variable types

vmware.compute_resources (Restricts Compute Resources that can be used)

cloud.location

Yes

Datacenter identifier

string

vmware.custom_instance_type.maximum_cpu (Sets a maximum number of VCPUs for custom instance types)

cloud.location

No

Datacenter identifier

number

vmware.custom_instance_type.maximum_ram (Sets a maximum size for custom instance types in GB)

cloud.location

No

Datacenter identifier

number

vmware.custom_specs (Restricts customization specs can be used)

cloud.location

No

Datacenter identifier

string

cloud.compute_resource

No

Compute resource identifier

vmware.host_systems (Restricts Hosts that can be used)

cloud.location

Yes

Datacenter identifier

string

cloud.compute_resource

Yes

Compute resource identifier

vmware.resource_pools (Restricts Resources pools that can be used)

cloud.location

Yes

Datacenter identifier

string

cloud.compute_resource

Yes

Compute resource identifier

vmware.storage.placements (Restricts datastores and storage pods can be used)

cloud.location

Yes

Datacenter identifier

string