Cloud Canvas Built-In Roles and Policies

You can use the built-in Cloud Canvas roles and policies to manage resource and deployment permissions for your project.

Built-In Roles

You can use the AWS::IAM:Role resource to define roles in your project-template.json or deployment-access-template.json files. Cloud Canvas Resource Manager defines the following roles for you.

DeploymentAdmin

Grants restricted access to the deployment. Similar to the DeploymentOwner role, but cannot create or delete resource group stacks. This is a convenience role that is safer than DeploymentOwner. To add additional restrictions to the DeploymentAdmin role, edit the DeploymentAdminRestrictions policy definition.

File location: \project_name\deployment_name\deployment-access-template.json.

DeploymentOwner

Grants full access to all the resources in a deployment. To modify the default permissions granted by this role, edit the DeploymentOwnerAccess policy definition.

File location: \project_name\deployment_name\deployment-access-template.json.

Note
Permissions added to DeploymentOwnerAccess are also granted to DeploymentAdmin unless they are denied by DeploymentAdminRestrictions.

Player

Grants players limited access to specific resources in a deployment as determined by permissions metadata on those resources.

File location: \project_name\deployment_name\deployment-access-template.json.

ProjectAdmin

Grants project administrators restricted access to all the project’s deployments. Similar to the ProjectOwner role, but cannot create, update, or delete deployments with names that start with “Release.” This is a convenience role that is safer than ProjectOwner. To add additional restrictions to the ProjectAdmin role, edit the ProjectAdminRestrictions definition.

File location: \project_name\project-template.json.

Warning
The intent of this role is to securely “sandbox” user actions so that they don’t accidentally impact other projects. However, anyone who can assume the ProjectAdmin role can grant themselves additional permissions. Because a ProjectAdmin user can escalate the privilege for the role, the ProjectAdmin role should still be considered an account administrator role and therefore a potential security concern.

ProjectOwner

Grants project administrators full access to all the project’s resources. To modify the default permissions granted by this role, edit the ProjectOwnerAccess policy definition.

File location: \project_name\project-template.json.

Warning
The intent of this role is to securely “sandbox” user actions so that they don’t accidentally impact other projects. However, anyone who can assume the ProjectOwner role can grant themselves additional permissions. Because a ProjectOwner user can escalate the privilege for the role, the ProjectOwner role should still be considered an account administrator role and therefore a potential security concern. Permissions added to ProjectOwnerAccess are also granted to ProjectAdmin unless they are denied by ProjectAdminRestrictions.

ProjectResourceHandlerExecution

Grants the ProjectResourceHandler Lambda function runtime execution permissions. This role grants permissions for Cloud Canvas Resource Manager to use AWS CloudFormation custom resources for stack operations. For more information, see Access Scenarios and the ProjectResourceHandler.

File location: \project_name\project-template.json.

Server

Grants Lumberyard dedicated server builds access to select deployment resources, as determined by permissions metadata on those resources.

File location: \project_name\deployment_name\deployment-access-template.json.

Role Scope

The configuration file in which you define a role determines the resources to which the role provides access.

You can use the lmbr_aws command line tool to manage the role definitions in the project-template.json and deployment-access-template.json files. For more information, see Using the Cloud Canvas Command Line to Manage Roles and Permissions.

Implicit Roles

Some Cloud Canvas custom resources also create roles. For example, when a Lambda function is executed, it assumes the role that the Custom::LambdaConfiguration resource creates. When API Gateway invokes a Lambda function or accesses other resources, it assumes the role that the Custom::ServiceApi resource creates. Including these custom resources in a resource-group-template.json file causes these implicit roles to be created \(and deleted when the resource is deleted\). For information on implicit role names, see Implicit Role Mappings.

Managed Policies

You can use AWS::IAM::ManagedPolicy resources to define permissions that are shared across any number of roles. Cloud Canvas defines the following managed policies for you:

The ProjectAdmin and DeploymentAdmin roles are granted the same permissions as the ProjectOwner and DeploymentOwner roles, minus any permissions specifically denied by the ProjectAdminRestrictions and DeploymentAdminRestrictions managed policies, respectively. In effect, an “admin” is granted all the permissions of an “owner” minus any special actions that the “admin” should not be able to perform.

Role Mapping Metadata

The AbstractRole property in the Permission metadata object does not directly specify the actual role that receives the described permission. These values must be mapped to actual IAM roles. This makes it possible to setup roles in whatever way makes sense for your project. It also removes the need to modify the permissions defined by individual resource groups.

The ability to map abstract roles to actual IAM roles is important when you use a cloud gem across multiple projects or from a third party. Cloud gems acquired from a third party might have roles that are different from the roles that you use in your organization. \(A cloud gem is a [Lumberyard gem](gems-system-gems.md) that uses the AWS resources defined by a Cloud Canvas Resource Group\. For more information, see [Cloud Gems](cloud-canvas-cloud-gems-intro.md)\.\)

The Custom::AccessControl resource looks for CloudCanvas RoleMappings metadata on AWS::IAM::Role resources to determine which abstract roles map to that physical role. In the following example, the CustomerSupport abstract role from all resource groups is mapped to the DevOps physical role.

...
  
"DevOps": {
    "Type": "AWS::IAM::Role",
    "Properties": {
        "Path": { "Fn::Join": [ "", [ "/", { "Ref": "ProjectStack" }, "/", { "Ref": "DeploymentName" }, "/" ]] }
    },
    "Metadata": {
        "CloudCanvas": {
            "RoleMappings": [
                {
                    "AbstractRole": [ "*.CustomerSupport" ],
                    "Effect": "Allow"
                }
            ]
        }
    }
},
 
...

Each Cloud Canvas RoleMapping metadata object can have the following properties.

You can use the lmbr_aws command line tool to manage RoleMappings metadata on role resource definitions in the project-template.json and deployment-access-template.json files. For more information, see Using the Cloud Canvas Command Line to Manage Roles and Permissions.

Default Role Mappings

Cloud Canvas defines role mappings for the following roles:

Implicit Role Mappings

As mentioned in Implicit Roles, role mappings are automatically defined for the implicit roles created by Cloud Canvas resources like Custom::LambdaConfiguration. These mappings are only used with permission metadata in the same resource-group-template.json file as the custom resource that creates the role. The name of the abstract role used in permission metadata to reference an implicit role depends on the custom resource type.