Page tree
Skip to end of metadata
Go to start of metadata

The following Types of Policies are available for Cloud Specific Policy Groups:


Cloud-wide policies

Cloud Wide policies are available regardless of the specific Cloud Platform selected.

Tags policy


Short description

Sets a list of tags that will be applied to resources

Type

cloud.tags

Mandatory conditions

None

Optional conditions

Cloud, Location, OS Type


Scalr can ensure that certain tags (in AWS) or metadata (in OpenStack) automatically get added to the instances you provision, so as to let you ensure compliance with internal IT and accounting policies.

In order to allow a certain level of flexibility (e.g. you define a tag name in a Tagging Policy, and users can supply a value), Tagging Policies supports Global Variable Interpolation. A Tagging Policy is best used in conjunction with Required Global Variables.

Instances and volumes are tagged, and so are Amazon ELBs. Note that for ELBs, only Environment-Scope Global Variables are used for Global Variable Interpolation.


Example:


Instance name format policy

 

Short description

Sets a naming convention for instance names

Type

cloud.instance.name_format

Mandatory conditions

None

Optional conditions

Cloud, Location, OS Type


This policy is effective only on AWS and OpenStack cloud platforms.

If this policy is not enabled, the instance name template can be defined on a Farm-Role basis in the EC2 Tab or OpenStack Tab.

The Instance Name Policy supports Global Variable Interpolation.


Example:

Instance types policy

 

Short description

Restricts instance types that can be used in Farms

Type

cloud.instance.types

Mandatory conditions

Cloud

Optional conditions

Location, OS Type


You can restrict your users to a specific set of Instance Types. Start by selecting a Cloud Platform in the conditions for this policy. Scalr will fetch the available instance types and show them below. Tick the checkbox next to the instance types you want to allow.

Using a single instance type

If you use a single Instance Type, Scalr will not display a drop-down list in the Creating and Editing Farms.

Setting the default instance type

To set the default instance type your users will see when creating a new farm role, see Default Farm Role Settings


Example:


Locations policy

 

Short description

Restricts locations that can be used on a cloud

Type

cloud.locations

Mandatory conditions

Cloud

Optional conditions

None


You must select a Cloud Platform in the conditions for this policy. Once you have selected a Cloud Platform, the available locations will appear below. Tick the checkbox next to the locations you want your users to be able to create resource in.


Example:

Security Groups policy

 

Short description

Sets or Restricts Security Groups that can be used

Type

cloud.security_groups

Mandatory conditions

Cloud

Optional conditions

Location, Cloud Service


Start by selecting a Cloud Platform in the conditions for this policy. The security groups you specify below will be added to your infrastructure. You can also choose whether users will be able to specify additional security groups, and to restrict which security groups the can specify.

 

Affects Custom and System Security Groups

Unless you select the "Allow user to specify additional security groups" option, Custom Security Groups are disabled for your Farm Roles.

In any case, System Security Groups are disabled.

 

Security Groups must exist in your Cloud Platform

Scalr will not be able to launch your Servers (Instances) if the Security Groups you require do not already exist when instances are launched:

On AWS:

  • Ensure the Security Groups exist in all EC2 regions you intend to launch instances in

  • Ensure the Security Groups exist in all VPCs you intend to launch instances in

On OpenStack:

  • Ensure the Security Groups exist in all OpenStack regions you intend to launch instances in

 

Scalr needs access to your Instances

Scalr needs to be able to access your Instances to manage them. The scalr.ip-pool Security Group is automatically created by Scalr in your Cloud Platform, and gives Scalr this access.

If you use the Security Groups Policy, it is recommended that you add the scalr.ip-pool Security Group to your list.


Example:

Networks policy

 

Short description

Restricts networks (VPCs, VLANs) that can be used

Type

cloud.networks

Mandatory conditions

Cloud, Location

Optional conditions

None


You must set a Cloud and a Cloud Location in the conditions for this policy. Once you have done so, the available networks will appear below. Tick the checkbox next to the networks you want your users to be able to access.


Example:


Subnets policy

 

Short description

Restricts subnets that can be used inside networks

Type

cloud.subnets

Mandatory conditions

Cloud, Location, Network

Optional conditions

None


You must select a Cloud, a Cloud Location and a Network in the conditions for this policy. Once you have done so, the available subnets will appear below. Tick the checkbox next to the subnets you want your users to have access to.


Example:



AWS specific Policies


EC2 Key Pairs policy

 

Short description

Sets a specific SSH key pair on all instances

Type

aws.ec2.key_pair

Mandatory conditions

None

Optional conditions

None

Make sure that the key pair you specify exists in your EC2 account, because instances will fail to launch otherwise.


Example:


Generating a SSH Key Pair:


You can create a SSH Key Pair using the EC2 Console (https://console.aws.amazon.com/ec2/). In the EC2 Management Console, click on Key Pairs in the bottom of the left hand column. 



Then click on Create Key Pair in the EC2 Management Console to generate a new Key Pair.



Alternatively, you can generate a SSH Key Pair manually using the following command line invocation. Keep in mind that you will need to import the Key into the EC2 Console for it to be usable by Scalr.


ssh-keygen -f my-scalr-key




KMS Keys policy

 

Short description

Restricts KMS keys available for storage encryption

Type

aws.kms.keys

Mandatory conditions

Location

Optional conditions

Cloud service


You must select a Cloud Location in the conditions for this policy. Once you have done so, the available KMS keys will appear below. Tick the checkbox next to the keys you want to allow.


Example:

VPC required policy

 

Short description

Requires resources to be created in a VPC

Type

aws.network.require_vpc

Mandatory conditions

None

Optional conditions

None


Example:

IAM Instance profiles policy

 

Short description

Restricts IAM instance profiles that can be applied to instances

Type

aws.iam.instance_profile

Mandatory conditions

None

Optional conditions

None


The available IAM instance profiles appear in the Allowed IAM Instance Profiles section. Tick the checkbox next to the profiles you want to allow. This restricts the available instance profile options in the Farm Designer.


Example:

Storage encryption policy

 

Short description

Requires storage to be encrypted with a KMS key

Type

aws.storage.require_encryption

Mandatory conditions

None

Optional conditions

Cloud service


Example:

RDS Instance farm association policy

 

Short description

Requires RDS instances to be associated with a Farm

Type

aws.rds.instance.require_farm_association

Mandatory conditions

None

Optional conditions

None


Example:


Subnet type policy

 

Short description

Restricts subnets types to either Public or Private

Type

aws.network.subnet_type

Mandatory conditions

None

Optional conditions

Location, Network


Example:

Azure specific Policies


Public IP usage policy

 

Short description

Sets public IPs on all instances or none

Type

azure.network.public_ip_usage

Mandatory conditions

None

Optional conditions

Location


Example:


Resource groups

 

Short description

Restricts Resource Groups that can be used

Type

azure.resource_groups

Mandatory conditions

None

Optional conditions

None


Example:

OpenStack specific Policies



SSH Key Pair policy


Short description

Sets a specific SSH key pair on all instances

Type

cloud.ssh.key_pair

Mandatory conditions

Credentials

Optional conditions

None

Make sure that the key pair you specify exists in your cloud account, because instances will fail to launch otherwise.

Example:



Generating a SSH Key Pair:

Follow the SSH Key Pair generation procedure for your cloud provider.  Alternatively, you can generate a SSH Key Pair manually using the following command line invocation. Keep in mind that you will need to import the Key into your cloud provider Console for it to be usable by Scalr.

ssh-keygen -f my-scalr-key





  • No labels