Migrate to  a Tagless Governance Environment

The information in this section does not apply to fresh installations!

Overview

In CloudCenter 4.10, governance, the restriction of which policies can be applied to deployments, is no longer implemented using system tags. Instead, governance is enforced by defining lists of allowable deployment-wide aging, suspension and security policies (formerly called security profiles) in the deployment environment, and by defining lists of allowable deployment environments and per-tier scaling policies in the application profile.

System Tags remain but are used for metadata purposes only. For more details on the changes associated with the new tagless governance feature, see the CloudCenter 4.10.0 release notes.

In CloudCenter 4.10, all users and all applications using the same deployment environment are governed by the same set of allowed policies (aging, suspension, and security). If different users or applications require different sets of allowed policies at deploy time, then these users can create additional deployment environments to account for each permutation.

Pre-Upgrade Requirements

BEFORE the upgrade

The root tenant admin must first execute these steps and then ensure that each tenant admin subsequently performs these steps for their tenant.

Before starting the upgrade process, execute these steps:

StepGoalProcedure
1Record all governance rules,

To record the mappings of tags to deployment environments, policies and security profiles, follow this procedure:

  1. Navigate to Admin > Governance Rules and make sure the Governance Rules toggle is turned on. 

  2. Take screenshots or copy and paste the details to a spreadsheet that records all governance rules details.

2

Confirm that no governance rule contains the AND function.

To verify that the AND function is not used in any governance rule, follow this procedure:

  1. Using the governance rules list captured in Step 1 above, for each rule in the first column, confirm that there are no AND functions in any of the rules.

  2. If no governance rule contains the AND function, continue below. If any governance rule contains the AND function, stop! Consider redesigning these rules to eliminate the AND function before continuing.

3Determine if any sub-tenant or sub-tenant user requires access to a tag created in your tenant.

To verify sub-tenant/user tag access, follow this procedure:

  1. Navigate to Admin > System Tags

  2. For each tag, select share and note if it is shared with a sub-tenant or sub-tenant user.

  3. Compile a list of all tags that are shared with at least one sub-tenant or sub-tenant user.

4Determine if any sub-tenant or sub-tenant user requires access to a security profile created in your tenant.

To verify sub-tenant/user security profile access, follow this procedure:

  1. Navigate to Admin > Security Profiles.

  2. For each security profile, select share and note if it is shared with a sub-tenant or sub-tenant user.

  3. Compile a list of all security profiles that are shared with at least one sub-tenant or sub-tenant user.

5Determine if any sub-tenant or sub-tenant user requires access to an event, aging, suspension, or scaling policy created in your tenant.

To verify sub-tenant/user policy access, follow this procedure:

  1. Navigate to Main > Policies.

  2. For each aging, suspension and scaling policy, select Share and note if it is shared with a sub-tenant or sub-tenant user.

  3. Compile a list of all aging, suspension and scaling policies that are shared with at least one sub-tenant or sub-tenant user.

6Determine if any deployment environment is associated with more than one tag

To verify association with multiple tags, follow this procedure:

  1. Follow Step 1 in this table for each tag.
  2. Take note of all multi-tag deployment environments.
7Determine if any application profile has tags that override the aging, suspension, or security policies of a deployment environment in which the application is allowed to run

To verify overriding tags, follow this procedure:

  1. Navigate to CCM UI's App Profiles list page

  2. For each app profile do the following:

    1. Click edit/update to go to the topology modeler tab of the app profile. 

    2. Click the Basic Information tab and observe all of the tags in this the tags field. Using the tag mappings captured in pre-upgrade step 1 as a guide, note which tags in the app profile are associated with deployment environments and which tags are not.

    3. For each tag in the app profile that is NOT used to associate the app profile with a deployment environment (non-deployment environment related tag), using the governance rules captured in pre-upgrade Step 1 as a guide, determine if that tag would invoke an aging, suspension or security policy that is contrary to what would be invoked by any of the deployment environment related tags. For example, if the app profile has a deployment environment associated tag called dev, and the dev tag is also associated with a one_week aging policy at priority 2 in the list of aging policies, but the app profile also has a tag called "one_month" associated with a one_month aging policy at priority 1 in the list of aging policies, then if the app is deployed to the dev environment, it would be deployed with the one_month aging policy and not the one_week aging policy associated with the dev environment. 

    4. Note all non-deployment environment related tags in the app profile that override policies associated with any of the deployment environment related tags.

8Determine if any Role requires access to a additional resources.

To verify role access, follow this procedure:

  1. Navigate to Admin > Roles.

  2. For each role, note the resources that have been assigned.

  3. Compile a list of all user roles.

9Determine your use case!
  • If each deployment environment is associated with only one tag (Step 6) AND no app profile has any non-deployment environment associated tags that would cause conflicts with its deployment environment associated tags (Step 7), your use case is a Simple case.
    Continue with the Simple Case, Post-Upgrade section below after your system upgrade completes.

  • If either of these conditions (Step 6 and 7) are false, your use case is a Complex case.
    Continue with the Complex Case, Post-Upgrade section below after your system upgrade completes.

Upgrade Instructions

Follow the Upgrade Overview instructions to upgrade your system to 4.10.

You cannot use an old response file when upgrading to CloudCenter 4.10.0.

Download the new ccm-response.xml file as part of the Upgrade CCM procedure – the CloudCenter 4.10.0 ccm-response.xml file has a new value  “key=migrate_gov value=false

Change the default value to true for this migration to work."

The first time you upgrade to CloudCenter 4.10, you will see a warning informing you about this requirement. Further upgrades does not display the warning and or require a new ccm-response.xml file to proceed

Post-Upgrade Use Cases

This section addresses the following use cases:

#QualificationThe AND FunctionUse Case Details
1UnaddressedAt least one governance rule uses the AND function

This use case is too complex!

It is more efficient for you to redesign your tag-based governance implementation to eliminate any governance rule that uses the AND function prior to upgrading.

2SimpleNo governance rule uses the AND functionThe simple use case has these characteristics:
  1. Each deployment environment is associated with only one tag.

  2. Each policy and security profile that can be used in a deployment environment is associated with the same tag that is associated with the deployment environment.

  3. No application profile contains tags that would override the aging policies, suspension policies, or security policies of a deployment environment in which the application is allowed to run.

Procedural details are available in the Simple Case, Post-Upgrade section below.

3ComplexNo governance rule uses the AND functionThe complex use case has these characteristics:
  1. Either or both of these two conditions is true:

    1. At least one deployment environment is associated with more than one tag.

    2. At least one application profile contains a tag that would override the aging policies, suspension policies, or security profiles of a deployment environment in which the application is allowed to run.

  2. Each policy and security profile that can be used in a deployment environment is associated with at least one of the tags to which the deployment environment is associated.

Procedural details are available in the Complex Case, Post-Upgrade section below.

Simple Case, Post-Upgrade

AFTER the upgrade

AFTER the upgrade, the root tenant admin must first execute these steps and then ensure that each tenant admin subsequently performs these steps for their tenant.

To address a Simple migration, follow this procedure.

Use the screenshots (or spreadsheet) of governance rules that you created in Step 1 of the Pre-Upgrade Requirements section as a reference for the following steps.

  1. Update the deployment environments. From the CCM UI, navigate to the Environments page. For each deployment environment created in the tenant, select Edit and perform the following steps:

    1. Set the allowed and required tags (optional). The Tags dropdown field in the General Settings tab lists available tags and allows you to select multiple tags. You can also lock/unlock any tag (and make the tag a required/optional configuration) by clicking the unlock/lock icon in the dropdown list. The System Tags section provides additional details on tags.

    2. Set the policies for each environment. Navigate to the Environment > Policy Settings tab.

      For each policy:

      • If only one policy is selected, the visibility toggle to the left of the dropdown is enabled and set to ON but it can be turned off.

      • If at least one policy is selected from the dropdown list a mandatory toggle is enabled but set to OFF by default.

      • The All option in the dropdown list will cause all aging policies available to this tenant to be displayed at deploy time. Even with the All option selected, it is possible to pin any individual policy as the default by clicking the policy's pin icon in the dropdown list.

      • To the right of the policy dropdown field is a deploy time preview section. This section shows what the corresponding policy field looks like in the Deploy form at deploy time.


      1. Set the allowed aging policies using the dropdown list. Select each aging policy from the dropdown list that used to be associated with a tag associated with the deployment environment. For example, for the dev environment, select all aging policies that used to be associated with the dev tag.

      2. Set the allowed suspension policies using the dropdown list. In addition, the suspension policies section has an Allow terminate/suspend protection toggle which is enabled (ON) by default. Adjust this toggle as appropriate for the deployment environment.

      3. Set the allowed and pre-selected security policies using the two dropdown lists. Since several security policies may be selected at deploy time, instead of allowing one default policy that is pinned to the dropdown list, the security policies section also has a pre-selected security policies dropdown list to pin multiple security policies in the deploy form.

    3. Save the deployment environment by clicking Done.

  2. Update the application profiles. From the CCM UI, navigate to the App Profiles page. For each app profile created in the tenant, select Edit and perform the following steps:

    1. Set the allowable deployment environments for each app profile using the new dropdown list.

      1. Click the app profile's Basic Information tab.

      2. Find the new toggle switch labeled Specify Deployment Environment? and turn it ON. This will reveal the dropdown field labeled Allowed Deployment Environments.

      3. Using the application-level tags in the Associate Tags as a guide, select the appropriate deployment environments from the dropdown list.

    2. Set the allowable scaling policies of each appropriate tier of the application.

      1. Click the app profile's Topology modeler tab.

      2. For each tier that can scale:

        1. Select the tier by clicking on the tier icon.

        2. In the Properties panel on the right, click General Setting  and scroll to the bottom to reveal the Allowed Scaling Polices.

        3. Using the application-level tags in the Associate Tags as a guide, select the appropriate deployment environments from the dropdown list.

          If an application profile had a per-tier scaling policy set when governance rules were turned off before the upgrade, then after the upgrade the scaling policy for this tier is set to the All option and the scaling policy that was set before the upgrade is now pinned as the default policy.

          You can no longer associate security policies with an application tier in the app profile.

          However, you can set deployment-wide security policies in the deployment environment, and if deploying to an environment with several allowed security policies, you can apply different security policies to different tiers at deploy time. 

          If you want an app profile to have different security policies for different tiers independent of the deployment environment, consider defining per tier firewall rules for each tier instead.

    3. Save the app profile by clicking Save App.

  3. Set the "share with subtenants" option on selected tags. From the CCM UI, navigate to the Admin > System Tags page. Turn on the Share with all tenants toggle for each required tag.

  4. Set the Share with all tenants option for each selected policy.

    1. From the CCM UI, navigate to the Admin Policies page.

    2. Go down your lists of security profiles and policies that require sharing outside the tenant and turn on the Share with all tenants toggle for each required policy.

      It is only necessary to use this feature if you want users outside of your tenant to use a policy in an app profile or deployment environment that the user has built or has modify access to.

      It is NOT necessary to explicitly share policies embedded in deployment environments or app profiles that are shared with users outside the tenant.

  5. Grant the View or Edit policies privilege to the select list of users with the standard user role. From the CCM UI, navigate to the Admin > Roles page.

    After the upgrade, the permission to view and edit policies is removed from standard users. If some of the standard users in your tenant need the ability to see and edit policies created in your tenant, create a new standard user with policy role and add those users to the new role.

    1. Click Add Role to view the Add a New User Role form.

    2. In the General Information section, add the standard user with policy role.

    3. In the Permissions section, check the boxes for Application Profile and Policy.

    4. In the Users section's Add user to this role field, begin typing the email address of the first standard user that needs access to see and edit policies. A list of matching users will appear in a dropdown list as you are typing. Select the appropriate user.

    5. Repeat Step 5d for all standard users needing the Policy permission.

  6. Grant the assigned role-based permission for all other roles. From the CCM UI, navigate to the Admin > Roles page.

    After the upgrade, the role-based permission for each resource is unchecked by default (other than for the Admin and Ops out-of-box roles).

    1. Click Edit Role to view the Edit User Role form.

    2. In the Permissions section, check the boxes for the resources logged in your list.

    3. Repeat these steps for all roles needing modified permission.

You have now completed the post-upgrade requirements for a simple use case!

Complex Case, Post-Upgrade

Each tenant admin must execute this procedure on their own tenant after the system upgrade.

The complex use case addresses migration nuances where at least one deployment environment requires different allowed policies for different users, or different allowed policies for different applications. In either case, the administrator must duplicate the deployment environment a sufficient number of times to account for all possible permutations of users and apps requiring different policies for the same deployment environment at deploy time.

Duplicating involves creating a new deployment environment with the same combination of cloud regions, cloud accounts, network mappings, and cloud defaults as the original deployment environment. To determine how many times you need to duplicate a deployment environment, consider the following examples.

Example 1: Some Resources Shared with Some Users

This example assumes that different users deploy to the same environment but use different policies.

Prior to the upgrade, a tenant administrator had created a deployment environment's public_cloud and associated it with with two tags:

  • dev_public, shared with dev users – associated with a one_week aging policy

  • ops_public, shared with ops user – associated with a one_month aging policy

This data should have been recorded in the governance rules screenshots or spreadsheet created during Step 1 of the process required in the Pre-Upgrade Requirements section and is displayed in the following image.

The solution to this example is to create two environments, each with different policies, shared to different users as displayed in the following image.

In this solution, you should make sure to perform the following tasks.

  1. Rename the public_cloud environment to public_cloud_dev.

  2. Set the tags and policies for this environment as described in simple case post upgrade Step 1. Make sure that this environment includes the one_week aging policy but not the one_month aging policy.

  3. Change the sharing of this environment to include only the dev users among the original list of users.

  4. Create a new environment called public_cloud_ops and ensure that it has the same combination of cloud regions, cloud accounts, network mappings, and cloud defaults as the public_cloud_dev environment.

  5. Set the tags and policies for this environment as described in the Simple Case, Post-Upgrade section Step 1. Make sure that this environment includes the one_month aging policy but not the one_week aging policy.

  6. Set the sharing of this environment to include only the ops users who originally had access to the public_cloud environment.

Example 2: All Resources Shared with All Users

This example assumes that all mentioned app profiles, deployment environments, policies and tags are shared with all users.

Prior to upgrade, a tenant administrator had created a deployment environment dev_cloud and associated it with the tag dev_cloud. The dev_cloud tag was also associated with the following aging policies:

  • The one_month aging policy at Priority 2 in the list of aging policies.

  • The one_week aging policy at Priority 1 in the list of aging policies – associated with the one_week tag.

This data should have been recorded in the governance rules screenshots or spreadsheet created during Step 1 of the process required in the Pre-Upgrade Requirements section and is displayed in the following image.

The admin also created an app profile named App_A. App_A's app-wide tag list has both the dev_cloud tag and the one_week tag. Other app profiles exist, such as App_B, that also have the dev_cloud tag, but none of these other app profiles contain the one_week tag or any other tag that would conflict with the one_month aging policy associated with the dev_cloud tag. In the tag-based governance model, this scenario results in App_A being deployed to the dev_cloud with the one_week aging policy and all other applications being deployed to the dev_cloud with the one_month aging policy.

The solution to this example is to create two environments, each with different policies, and each application profile referencing the appropriate environment.

In this solution, you should make sure to perform the following tasks.

  1. Set the tags and policies for the dev_cloud environment as described in simple case post upgrade step 1. Make sure that this environment includes the one_month aging policy but not the one_week aging policy.

  2. Create a new environment called dev_cloud_one_week and ensure it has the same combination of cloud regions, cloud accounts, network mappings, and cloud defaults as the dev_cloud environment.

  3. Set the tags and policies for this environment as described in Simple Case, Post-Upgrade section Step 1. Make sure that this environment includes the one_week aging policy but not the one_month aging policy.

  4. Set the sharing of this environment to include the same users who have access to the dev_cloud environment.

  5. Edit the App_A app profile and include the dev_cloud_one_week environment in the list of allowed deployment environments. Make sure the dev_cloud environment is not in this list.

  6. For all other app profiles containing the dev_cloud tag, such as App_B, make sure the dev_cloud environment is included in the list of allowed deployment environments but the dev_cloud_one_week environment is not included.

Using these two examples as guides, create all of the additional deployment environments needed for your use case and set the tags and policies for each environment following the procedure in simple case post deployment step 1.

Next, continue with Steps 2 through 6 in the in Simple Case, Post-Upgrade section. In Step 2, remember to consider cases like Example 2 above when setting the allowed deployment environments for each app profile.

You have now completed the post-upgrade requirements for a complex use case!


  • No labels
© 2017-2019 Cisco Systems, Inc. All rights reserved