You define day 2 action policies so that you can control what changes your users can make to deployments and their component resources. By creating a list of permitted actions that all or some users can run on deployments, you ensure that the users cannot initiate any destructive or costly changes. The use cases related to day 2 actions policies are an introduction to the procedure.

When you entitle users to run day 2 actions, you select the individual actions that they can run. You are creating an inclusion list, not an exclusion list.

When does a day 2 actions policy go into effect?

  • If you do not have any Day 2 Action policies defined, then no governance is applied and all users have access to all the actions. This initial lack of governance as you are starting out ensures that you and your users can exercise the day two actions in Service Broker and Cloud Assembly without the need to understand day 2 policies.
  • After you determine that you are ready to control who has access to what actions, you add governance in the form of a single Day 2 Action policy. When the first policy goes into effect, the Day 2 Action policies are enforced for all users in Service Broker and Cloud Assembly. As a result, only the users for whom the first policy is true can run the selected actions. All others are excluded. They are excluded because the actions policies include the trusted users. By excluding all others, you are able to craft the policies to match your governance goals.
  • To entitle other users, you must create policies that entitle them to run the actions you select.

Deployment sharing in projects affects how you configure the day 2 actions entitlements. If the project is not set to share, then only the requesting user can see a deployment. If the project shares deployments, then all the members of the project can see the deployment, and run any actions that they are entitled to run by a Day 2 Action policy. Deployment sharing is configured in a project. Select Infrastructure > Administration > Projects, then select the project and click the Users tab.

As you create your policies, the way that you define Day 2 Actions policies must take sharing status into consideration.

To focus when the Day 2 Actions policies are applied, you can configure scope, role, and criteria. These configurations control what deployments the policy is applied to and who can run the actions when the policy is enforced.

  • What deployments the policy is applied to.
    • Scope determines whether the policy is applied to deployments at the organization or project level.
    • Criteria narrows the scope of the policy to particular aspects of deployments.
  • Who can run what actions on those deployments.
    • Role entitles the members of the selected role, within the selected scope and criteria, to run the selected actions. The role can be project administrator, project member, or a named custom role.

Day 2 policies are enforced when a user tries to manage a deployment using the Actions menu on the deployment or on the component resources.

In this use case, which is used to illustrate a collection of day 2 action policies, the assumption is that you enabled deployment sharing in the project.

As you review the day 2 actions policies use case, you must also select the actions. You must select the actions that support your cloud accounts.

  • Actions are cloud specific. When you are entitling the users to make changes, consider what cloud accounts the entitled users are deploying to and ensure that you select all the cloud-specific versions of the actions. For example, add Cloud.AWS.EC2.Instance.Resize, Cloud.GCP.Machine.Resize, and Cloud.Azure.Machine.Resize to entitle users to resize those machines.
  • Cloud agnostic actions, for example, Cloud.Machine.Resize, exist to accommodate resources where the on-boarding or migration process cannot identify the machine type. If you entitle users to the cloud agnostic actions, you have not entitled them to run the cloud-specific action that will make the changes to the deployed resources. The agnostic actions might appear in the action menu, but running the actions has no effect. You should avoid entitling the agnostic actions and only entitle cloud-specific actions to ensure that actions are available to the users for your various cloud platforms.

Prerequisites

  • For a list of possible actions, see What actions can I run on Service Broker deployments.
  • For more information about constructing deployment criteria, see How do I configure deployment criteria in Service Broker policies.
  • Custom roles are used in Day 2 Policy 4. Create a Deployment Troubleshooter role, but with the Manage Deployment role in the custom Deployment Troubleshooting role does not limit the members by project. The Manage Deployment role allows the assignees to see all deployments and run all actions. If the Troubleshooting Deployments role does not include Manage Deployments, then the assignees see deployments based on their project membership. For more information about custom roles, see custom role use case.

Procedure

  1. Select Content and Policies > Policies > Definitions > New Policy > Day 2 Actions Policy.
  2. Configure Day 2 Policy 1.
    As an administrator, you want to control storage costs by restricting the ability of users to request snapshots.
    1. Define when the policy is valid.
      Setting Sample Value
      Scope Organization

      This policy applied to all deployments in your organization.
      Criteria None
      Enforcement type Soft

      This enforcement type allows you to create other policies related to the snapshot actions that override this policy.
      Role Member

      This role applies the policy to all project members.
    2. Select the actions that the users can run, but do not select any snapshot actions.
      You explicitly entitle users to run actions. To exclude users from running snapshot actions, ensure that the actions are not selected.
    In this scenario, none of the project members in your organization are entitled to create snapshots. Nor can your project administrators. Your next step is to create a policy that entitles the project administrators to create and manage snapshots.
  3. Configure Day 2 Policy 2.
    As an administrator, you want to give the project administrators the ability to create and manage snapshots.
    1. Define when the policy is valid.
      Setting Sample Value
      Scope Organization

      This policy is applied to all deployments in your organization.
      Criteria None
      Enforcement type Soft

      This enforcement type allows you to create other policies related to the snapshot actions that override this policy.

      Role Administrator

      This role applies the policy to the project administrators.

    2. Select the snapshot actions that you want the administrators to run.
      Project administrators are also entitled to run any actions that the members of their projects are entitled to run. You do not need to give them permission to member actions.
    In this scenario, the project administrators are entitled to run the snapshot-related actions and all the actions that their project members are entitled to run.
  4. Configure Day 2 Policy 3.
    As a project administrator, you have two developers who are doing work that potentially makes a deployment unusable. You want to entitle them to snapshot and revert without your intervention. You entitle the two project members to use the snapshot actions.
    1. Define when the policy is valid.
      Setting Sample Value
      Scope Project MT5

      This policy applied to deployments associated with this project.
      Criteria 
      Catalog Item equals Multi-tier five machine with LB 
AND 
    (Created By equals [email protected] 
    OR 
    Created By equals [email protected])

      Based on this criteria expression, only the deployments where Jan or Kris deployed a catalog item named Multi-tier five machine with LB are considered for policy enforcement.
      Enforcement type Hard

      This enforcement type ensures that the policy is enforced based on the definition.

      Role Member

      This role applies the policy to the catalog item defined in the deployment criteria.
    2. Select the snapshot actions that you want the specified users to run.
      Project administrators are also entitled to run any actions that the members of their projects are entitled to run.
    In this scenario, Jan and Kris can use the snapshot actions on the Multi-tier 5 Machines with LB catalog item that either of them deploy. Although other members of the project can see the deployment, only Jan, Kris, and the project administrator can use the snapshot actions.
  5. Configure Day 2 Policy 4.
    As an administrator, you want to assign the permissions to run most of the day 2 actions to the users who are assigned to a Deployment Troubleshooter custom role. While most custom role permissions go across projects, what users can see in the Deployments page is based on their project membership. To see the deployments, the users who are assigned the custom roles must be members of the projects that deployed them.
    1. Define when the policy is valid.
      Setting Sample Value
      Scope Organization
      Criteria None
      Enforcement type Soft

      This enforcement type allows you to create other policies related to the extended day 2 that override this policy.
      Role Select the Deployment Troubleshooter role.
    2. Select all the actions that you want the members of this custom role to be able to run.
    In this scenario, all the users with the Deployment Troubleshooting role can manage all deployments and run all selected day 2 actions across projects. The Manage Deployments role grants service administrator privileges on deployments so that they can run any action that a service administrator can run. If the Deployment Troubleshooting custom role does not include the Manage Deployments role, the users can run all the selected day 2 actions for the deployments belonging to their projects.

What to do next