Policy Management

About Policies 

A policy causes the CloudCenter platform to perform configured activities when certain events or conditions occur. For example, a policy could cause the CloudCenter platform to send an email alert message to a designated administrator if a cloud goes down. You use the Policies window to configure the following types of policies:

  • Event Policy– Causes the CloudCenter platform to send an email message, invoke a web service, execute a command or script, or perform any number and combination of these activities when a designated event occurs.

  • Scaling Policy – Causes the CloudCenter platform to increase or decrease VM resources for each application deployment tier that is associated with the policy when one or more designated conditions occur.

  • Aging Policy – Causes the CloudCenter platform to suspend and optionally terminate each application deployment that is associated with the policy after the deployment has been running for a designated period of time term.

  • Suspension Policy – Specifies a schedule for when a deployment should be in Running state.

Custom Actions are now defined in a new Actions Library tab.

Share with Sub-tenants

A policy is a tenant-owned resource that can be shared with other sub-tenants and users in the hierarchy.

  • The users directly under the owner tenant have Manage access to the policy as long as they have the Policy permission inherited through a role. However, subtenants and users further down the hierarchy can only have View access to the policy in read-only mode, if the policy is shared with subtenants.

  • If you do not have the Policy permissions inherited through a role, the Policy tab is hidden from your view.

  • All Policy pages have a Share with Sub-tenants toggle switch column:

    • On: Users in tenants that are further down the hierarchy can only View (read only) these policies, if shared.

      This setting provides visibility to having a role-based permissions for the required policy (see Permission Control > Role-Based  Permissions for details).

    • Off: Default. No user in any sub-tenant can view or use a policy in this state. The tenant admin can grant permissions to sub-tenants by enabling the (ON) toggle switch for the required policy.

When a deployment environment or application profile is shared with a sub-tenant or users in a sub-tenant, all policies (and system tags) associated with that environment or application profile can still be used in the shared environment or application profile.

Event Policies

An event policy causes the CloudCenter platform to perform one or more configured activities when a designated event occurs for the designated resource. These activities can be:

  • Email–Sends an email message with the designated subject and body text to the designated recipient or recipients

  • Invoke a web service–Executes the designated web service request

  • Execute a command–Executes the designated command or script on an application VM

Check the Auto Enable for Sub-Tenants checkbox (only applicable to Event policies) to automatically enable a policy for all shared users and groups. This option determines if the policy should be auto enabled for the sub tenants and users with whom the policy has been shared.

If you select the Auto Enable for Sub-Tenants checkbox, you also have the option to select the Restrict users from disabling this Policy checkbox to determine if the sub-tenants and users with whom the policy has been shared would be able to disable this policy.

To manage event policies, click Policies in the CCM UI main menu and then click the Event link to display the Events Policies page.

The Events Policies page lists configured event policies and lets you perform the tasks that the following table describes.

TaskDescription
Add a new event policy.

Click the New Event Policy link.

See Configuring an Event Policy for details.

View configurations for an existing event policy.

Click the policy name in the Name column.

The View page for the policy displays. See Configuring an Event Policy for details.

  • Description – Optional description that was configured for the policy
  • Last Updated – Date and time that the policy was last updated
  • Share with Sub-tenants – Described in the Share with Sub-tenants section above.
Enable or disable an event policy.

Click the ON/OFF toggle button in the Enable Column for the policy.

When a policy is enabled, it executes when the configured event occurs.

Set permissions for an event policy.

Choose Share from the dropdown list in the Actions column for the policy.

See Permission Control > Policy Permissions for details.

Update configurations for an existing event policy.

Choose Edit from the dropdown list in the Actions column for the policy.

The Edit page for the policy displays. See Configuring an Event Policy for a description of the fields that you can update. If you make updates, click the Save button on the Edit page to save your changes.

Delete an event policy.

Choose Delete from the dropdown list in the Actions column for the policy.

See a history of event policy executions.

Click the Execution History link to the right of the list of policies.

The User Defined Policy Executions page displays. This page lists in reverse chronological order each policy that has executed. For each policy, the page displays the local date and time of execution, the name of the policy, and the name of the resource against which the policy was enforced. You can see details about a policy or resource by clicking the name of the policy or entity.

Configuring an Event Policy

When you add an event policy, you create a new policy based on configuration settings that you make. To add an event policy, click New Event Policy on the Event Policy page and then configure the settings that display. Click the Save button after you complete the configuration.

The policy must be enabled before it can execute.

The following table describes the settings for configuring an event policy.

SettingDescription
Execute For dropdown listChoose the resource against which the policy is enforced with the configured event occurs
On Event dropdown listChoose the event that, when it affects the configured resource, causes the policy to execute. See eventName for additional details.
Action Type dropdown list

Enter information in the fields that appear for the action type that you choose as follows. When entering information, you can include variables that are described in the Available Variables section at the top right of the page to customize an email message, web service request, command, or script with dynamic information.

  • Email action type – Enter information in the To, Bcc, Subject, and Body fields that appear, as appropriate.
  • Invoke a web service action type – Enter information in the Web Service URLHttp Request TypeContent Type, Command Params, and Body fields that appear, as appropriate. See Using Parameters > Parameter Type for additional context.
  • Execute a Command action type – Enter the desired command or script in the command/script field.

When you specify the script or command action type globally, these global policies are executed on all jobs/deployments. You can also configure these global policies to be executed on specific state changes – for example, if a job/deployment goes to a Resumed or Deployed state. On reaching those states, all the VMs for this job/deployment are executed.

  • Launch a new deployment action type – Set the cloud-specific default in the destination deployment environment for the cloud burst configuration.

    Be aware that the instance types and network defaults are used from the Deployment Environment in the destination job when using a cloud bursting policy. This action type allows other choices as well, however, a cloud bursting policy is only applicable if you use the following settings:

    • Execute for = Application Deployment:
    • On Event = Maximum cluster size limit 
    • Action Type = Launch a new deployment

    If you configure multiple instance types in the destination Deployment Environment Defaults, the CloudCenter platform selects the first instance type.

Event Policy Guidelines

Do not use your system administrator credentials to change the user's event policy. This change adversely affects the CloudCenter platform and does not notify the user.

Adhere to the following event policy guidelines:

  • If you use a group email and you don't want to disable all email notifications for this policy, all users who enabled that policy in the CloudCenter platform must disable it for the group to no longer receive emails.

  • If you use a token (for example, %myemail%) and this token is replaced with a user email, then the user with this email must disable the policy in the CloudCenter platform.

  • If you create custom email policies, only the default email policy is triggered.

Scaling Policies

A scaling policy causes the CloudCenter platform to increase or decrease VMs for each application deployment tier that is associated with the policy. You can configure the VM scaling to occur once or daily, or when one or more designated conditions relating to system metrics such as CPU, memory, or network usage occur at a specified polling interval. 

VM Metrics Frequency

The frequency of updates for VM metrics depends on the polling interval configured in your scaling policy. Two schedulers are used for each VM:

  • The first scheduler fetches the metrics from the operating system (for example, CPU, memory, and so forth at a polling interval frequency defined by user. If the user defines a polling interval at 15-second intervals CloudCenter provides the metrics from the OS at 5-second intervals.

  • The second scheduler calculates the average of all values provided by the first scheduler and uploads the metrics to the CCO. This upload to the CCO occurs at the user-defined, polling interval frequency. The CCO does not poll each VM.

CPU Calculation

The CPU threshold is calculated based on the first VM – assuming that all balanced servers have a similar usage. Once the scaling (up or down) is executed, the CloudCenter platform waits for the breach period to re-evaluate the policy.

To manage scaling policies, click Policies in the CCM UI main menu and then click the Scaling link to display the Scaling Policies page.

The Scaling Policies page lists configured scaling policies and lets you perform the tasks that the following table describes.

TaskDescription
Add a new scaling policy.

Click the New Scaling Policy link.

See Configuring a Scaling Policy for details.

View or update configurations for an existing scaling policy.

Choose Edit from the dropdown list in the Actions column for the policy.

The Edit page for the policy displays. See Configuring a Scaling Policy for a description of the fields that you can update. If you make updates, click the Save button on the Edit page to save your changes.

  • Description – Optional description that was configured for the policy
  • Last Updated – Date and time that the policy was last updated
  • Share with Sub-tenants – Described in the Share with Sub-tenants section above.
Set permissions for a scaling policy.

Choose Share from the dropdown list in the Actions column for the policy.

See Permission Control > Policy Permissions for details.

Delete a scaling policy.

Choose Delete from the dropdown list in the Actions column for the policy.

Configuring a Scaling Policy

When you add a scaling policy, you create a new policy based on configuration settings that you make. To add a scaling policy, click New Scaling Policy on the Scaling Policy page and then the settings that display. Click the Save button after you complete the configuration.

The following table describes the settings for configuring a scaling policy.

SettingDescription
Name fieldEnter a brief and unique descriptive name for the policy
Description fieldOptionally enter a brief description of the policy.
Type of scaling radio button

Choose Scheduled Scaling or Elastic Scaling.

  • Scheduled scaling causes the policy to increase and then decrease the number of VMs to the values that you designate according to the schedule that you designate. The schedule can cause the scaling cycle to occur once at the designated dates and times, or it can cause scaling cycle to occur every day at designated times.
  • Elastic scaling causes the policy to increase or decrease the number of VMs as needed based on configured conditions that the system detects at a specified polling interval and breach period.

The breach period refers to the period of time that the CloudCenter platform waits after one scale up or scale down action, before stabilizing the load.

Ideally, the breach period should be greater than (or equal to) the time taken by the scaling operation to launch a VM.

For example, if the time taken to:

  • Launch and configure a node = 5 to 7 minutes
  • Polling interval = 30 seconds
  • Breach period should be = 8 to 10 minutes
Add Scaling Schedule fieldsAppears if you have selected Scheduled scaling. Configure how often this policy runs, when it runs, and the number of VMs to which to increase and decrease.
Poling Interval fields

Appears if you have selected Elastic scaling. Choose a time length in the left field and choose a time unit in the right field. The system polls system metrics at this interval to determine if the conditions that this policy requires to execute are met.

Poling Interval

For example, if you configure a 6-second polling interval, your metrics collected in this time is divided by 3 to obtain the average value. The average value is sent to the CCO at the polling interval frequency. So in this example, the CPU data is collected every 2 seconds, and automatically sent to the CCO at 6-second intervals.

Breach Period fields

Appears if you choose Elastic scaling. Choose a time length in the left field and choose a time unit in the right field. If the policy executes, it will not execute again for this period of time. In this way, the system can stabilize after a condition occurs without the policy continually adjusting the system.

Breach Period

If any VM meets the specified criteria, CloudCenter executes the policy. In a load balanced cluster if one VM's metrics crosses the threshold, it is most likely that the other VM will reach that threshold. If CloudCenter detects any VM crossing the threshold, the policy is executed and the breach period is set. Once the breach period is set, the other VMs cannot execute the policy.

Auto Scale Percentage

Optional. Allows the CloudCenter platform to determine when auto scaling must be triggered, as described in the following table.

Auto scaling is triggered when metric results from a minimum number of nodes have crossed the defined threshold.

This minimum number of nodes is calculated based on auto scale percentage that is defined as part of the policy metadata.

If auto scale percentage is not defined as part of policy metadata, then the CloudCenter platform's Auto Scale Percentage calculation defaults to 70%. This default is defined in the config file.

If auto scale percentage is defined as part of policy metadata, then the user-configured Auto Scale Percentage value takes precedence.

Distributed locking mechanism handles HA scenarios.
Scale out condition fieldsAppears if you have selected Elastic scaling and causes the policy to increase the number of VMs according to the designated rule or rules. The Scale in condition fields cause the policy to decrease the number VMs per the designated rule or rules.
For each condition, you configure one or more rule sets. Within each rule set, you configure one or more rules. 
  • From the Match dropdown list for each rule set: 
    • Choose All to cause the scaling to execute when the situations that are defined by all rules in the rule set occur
      or 
    • Choose Any to cause the scaling to execute when a situation that is defined by any rule in the set occurs.
  • To add a rule set, click the ... icon.
  • To add a rule to a rule set, click the + icon within the rule set.
  • To remove a rule, click the Trash Can icon under the rule, and then click the yes link.

Aging Policies

An aging policy causes the CloudCenter platform to suspend and optionally terminate each application deployment that is associated with the policy after the application deployment has been running for a designated period or reaches a designated deployment cost.

An aging policy and the prevent termination feature cannot be used simultaneously for a deployment because both items control the terminate and suspend behavior of VMs that are mapped to a deployment.

The Prevent Termination feature is only applicable to N-tier jobs. See Terminate Protection for additional context.

You can configure a grace period for an aging policy, which allows you to keep deployments in suspended state before the automated termination takes place. A grace period is particularly useful when approvals via ServiceNow are set up for extensions. You also can add  extensions to a policy, which allows deployments to keep running as needed.

If an aging policy is configured to terminate a deployment when the time or cost limit is reached, you optionally can configure a grace period, which allows you to keep deployments in suspended state before the automated termination takes place. A grace period is particularly useful if approvals via ServiceNow are set up for extensions. You also can add extensions to a policy, which allows deployments to keep running by adding more time/cost to permit runtime.

An aging policy can include notifications. A notification is an e-mail message to a deployment owner that informs the owner that the deployment is going to terminate or suspend or that a grace period for a deployment is going to expire. You can configure how far in advance of a termination or grace period expiration the system sends the message, and you can send additional messages as reminders.

You cannot modify duration, extension, or grace period settings for an Aging policy if a deployment is running with the policy enforced. You can modify notification options, which apply to future policy executions. If you need to modify duration, extension, or grace period settings, you can do so only when deployments that use the policy are no longer running or if you first manually remove the policy from all deployments that are using it.

The Aging Policy field in the Deploy form differs based on the following choices:

  • Off = A dropdown for selecting an aging policy

  • On = Displays the aging policies associated with tags that are assigned to the deployment

The Deployment Details page contains an Aging Policy dropdown with the following choices:

  • Change Policy lets you replace the current aging policy with another one that you pick from a list. If a policy specifies a time or cost that is less that what has accrued for the deployment, the policy is not available. 

  • Add Policy lets you add one from a list if one is not associated.

  • Remove Policy

To manage aging policies, click Policies in the CCM UI main menu and then click the Aging link to display the Aging Policies page.

The Aging Policies page lists configured aging policies and lets you perform the tasks that the following table describes.

TaskDescription
Add a new aging policy.

Click the New Aging Policy link.

See Configuring an Aging Policy for details.

Set permissions for an aging policy.

Choose Share from the dropdown list in the Actions column for the policy.

See Permission Control > Policy Permissions for details.

View information about an aging policy.

You can view the following information for each policy:

  • Description – Optional description that was configured for the policy
  • Last Updated – Date and time that the policy was last updated
  • Share with Sub-tenants – Described in the Share with Sub-tenants section above.
  • Extensions – If one or more extensions are configured for the policy, the number of extensions appears, followed by the time length or cost limit of each extension, in parentheses
  • Notify – Indicates whether email notification is configured for the policy
  • Age By – With the choice of how this policy should be aged, Time Duration or Cost Limit.
View or update configurations for an existing aging policy.

Choose Edit from the dropdown list in the Actions column for the policy.

The Edit page for the policy displays. See Configuring an Aging Policy for a description of the fields that you can update. If you make updates, click the Save button on the Edit page to save your changes.

Delete an aging policy.Choose Delete from the dropdown list in the Actions column for the policy
Enable or disable an aging policy.

Turn on or off the Enable switch for the policy.

When a policy is disabled, future deployments cannot use it. The policy remains in effect for existing deployments.

Configuring an Aging Policy

When you add an aging policy, you create a new policy based on configuration settings that you make. To add an aging policy, click New Aging Policy on the Aging Policy page and then configure the settings that display. Click the Save button after you complete the configuration.

To edit a numerical value field that contains a single digit, take either of these actions:

  • Change the single digit number to a two digit number, then delete the unneeded digit. For example, if the field contains the number 8 and you want to change that number to 2, type a 2 following the 8 in the field to make the number 82, then move your cursor to the left and delete the 8.

  • Change the single digit number to a two digit number, select the entire number, and then type the new number.

The following table describes the settings for configuring an aging policy.

SettingDescription
Age By buttonsClick Time Duration if you want to suspend and optionally terminate an application deployment after it has been running for a designated period, or click Cost Limit if you want to suspend or terminate a deployment when it reaches a designated deployment cost.
Policy Name fieldEnter a brief and unique descriptive name for the policy
Policy Description fieldOptionally enter a brief description of the policy.
Policy Duration fieldAppears if you choose a time duration policy type. Enter the duration as a number of units, such as 15 days.
Policy Cost Limit fieldAppears if you choose a cost limit policy type. Enter the cost amount.
Terminate Deployment after Policy Duration switch

Turn on if you want the deployments that are associated with the policy to terminate when the configured time duration or cost limit is reached.

By default, this switch is turned off and policies suspend but do not terminate when a duration or limit is reached.

Allow a Grace Period before Terminating switch

Appears if you choose to terminate deployments after the configured time duration or cost limit. Turn on this switch if you want to provide a grace period before a deployment is terminated.

A grace period is designated amount of months, days, or hours after configured time duration or cost limit is reached that deployments remain suspended before terminating. Enter the grace period as a number of units, such as 5 days, in the Grace Period fields. For example, if you choose to terminate deployments after 10 days and configure a grace period of 5 days, deployments become suspended when the 10 day duration is reached, remain suspended for 5 days, and then terminate.

Allow Extensions to this Policy switchTurn on if you want to provide the option of extending the time that the policy is in effect beyond the originally configured time duration or cost limit or a grace period
No. of Extensions fieldAppears if you allow extensions for the policy. For a policy that is to terminate a deployment after a designated period, enter duration of each extension as a number of units in the Length of Each Extension field. For a policy that is to terminate a deployment after a designated deployment cost, enter the additional cost that is allowed for each extension in the Cost Limit of Each Extension field. See Extensions for additional context.
Notify Deployment Owner of Policy Expiry switch

Turn on if you want the system to send an email message to a deployment owner notifying the owner that the deployment is going to terminate. In the Notify fields that appear, enter, as a number of units, how long before a deployment terminates the emails should be sent.

For example, you could enter 3 days. If you want to configure multiple messages regarding deployment termination, click Notification Alert and enter the number of units for each additional message. For example, in this way, you can configure the system to send messages 3 days, 2 days, and 1 day before termination. Edit text in the email body field, if needed, and optionally click View Sample E-Mail to see how the email message will appear to recipients.

Notify before Grace Period Ends switch

Turn on if you want the system to send an email message to a deployment owner notifying the owner that a grace period for a deployment is going to expire. In the Notify fields that appear, enter, as a number of units, how long before the grace period expires the emails should be sent. The period that you configure cannot be longer than the configured grace period so that the system does not send messages after the grace period expires.

For example, you could enter 3 days. Edit text in the email body field, if needed, and optionally click View Sample E-Mail to see how the email message will appear to recipients.

Suspension Policies

Suspension policies are designed to reduce cloud cost by suspending all tiers in a deployment at specific times – you can use a suspension policy to specify a schedule for when a deployment should be in the Running state. At other times, the deployment remains suspended. You can use a suspension policy to put a deployment in the Running state every day during a certain time period, or on specific days during a certain time period.

For example, you could configure the policy to put a deployment in a Running state every day from 8:00 a.m. through 9:00 p.m., or on Mondays, Wednesdays, and Fridays from 10:00 a.m. through 6:00 p.m. You also can specify one or more blockout dates, during which the deployment is suspended all day.

You can use this policy to conserve resources by taking a deployment out of Running state when it is not needed, or for preventing a deployment from running during times that it should not be accessed. It can also be useful to keep a deployment in a suspended state during a holiday or a holiday period.

On the Deployment Details page:

  • The Suspension Policy field's Add button allows you to associate a suspension policy. If a suspension policy is already associated, then you see a dropdown menu with the Change Policy and Remove Policy options.

  • Other new fields on the Deployment Details page include Start Time, Action History (new actions per new policies), and so forth.

To manage Suspension policies, click Policies in the CCM UI main menu and then click the Suspension link to display the Suspension Policies page.

The Suspension Policies page lists configured suspension policies and lets you perform the tasks described in the following table.

TaskDescription
Add a new suspension  policy.

Click the New Suspension Policy link.

See Configuring a Suspension Policy for details.

Set permissions for a suspension  policy.

Choose Share from the dropdown list in the Actions column for the policy.

See Permission Control > Policy Permissions for details.

View information about a suspension  policy.

You can view the following information for each policy:

  • Description – Optional description that was configured for the policy
  • Last Updated – Date and time that the policy was last updated
  • Share with Sub-tenants – Described in the Share with Sub-tenants section above.
  • Schedule – Runtime schedule and blockout dates that are configured for the policy
View or update configurations for an existing suspension policy.

Choose Edit from the dropdown list in the Actions column for the policy.

The Edit page for the policy displays. See Configuring a Suspension Policy for a description of the fields that you can update. If you make updates, click the Save button on the Edit page to save your changes.

Delete an suspension policy.

Choose Delete from the dropdown list in the Actions column for the policy.

Enable or disable a suspension  policy.

Turn on or off the Enable switch for the policy.

When a policy is disabled, future deployments cannot use it. The policy remains in effect for existing deployments.

The Savings Feature

The suspension policy savings feature displays expected compute time cost savings in the CloudCenter UI as described in the following table.

Savings DataDisplayed in the UI

The Save Up to column to the right of the Schedule column in the Policies > Suspension Policies list page.

This column lists the savings percentage for a suspension policy provide over time and is displayed in the following screenshot.

This indeterminate time period calculation is based on the uptime schedule (not blockout dates).

Blockout dates are not used in this calculation as the timeframe is indeterminate.

In the Create/Edit Suspension Policy form, the percentage savings field in the upper right of the blue header displayed in the following screenshot is updated when the user updates any of these four fields: start time, end time, repeat period, repeat every.

In the second part of the Deploy form, the percentage savings field in the upper right of the blue header is updated when the user changes the cloud, cloud region, or instance type as displayed in the following screenshot.


Expected monthly Savings per deployment based on a suspension policy is displayed in the currency for the logged in user

In the second part of the Deploy form, a Savings percentage is displayed next the Cost (per month) field. This is updated whenever the user changes the cloud, cloud region, or instance type.

Blockout dates are not used in this calculation as the timeframe is indeterminate.

In the Deployment list page, the monthly savings field is displayed in the Approx Savings column located next to the Cloud Cost column as displayed in the following screenshot.

For terminated deployments, this columns is blank. An Approx Cost column is also added to the right of the Run time column showing the hourly cost and estimated monthly cost based on the uptime schedule.

You can also add a policy in the Savings column on the Deployments list page. If a deployment does not already have an associated suspension policy, the Add Policy link is visible in the Savings column. Click the link to open a popup displaying a dropdown list of suspension policies. Next to each policy in the list is an info icon. Hovering over the icon displays an info balloon with the schedule of the policy and expected percent cost savings. Also, hovering over any of the savings entries in the savings column brings up a similar info balloon. You can select one of these suspension policies to add them to this deployment. The following screenshot displays the info icon and associated details for the specific suspension policy.


Configuring a Suspension Policy

When you add a suspension policy, you create a new policy based on configuration settings that you make. To add a  suspension policy, click New Suspension Policy on the Suspension Policy page and then configure the settings that display. Click the Save button after you complete the configuration.

The following table describes the settings for configuring a suspension policy.

SettingDescription
Policy Name fieldEnter a brief and unique descriptive name for the policy
Policy Description fieldOptionally enter a brief description of the policy.
Runtime Schedule fieldsEnter the start time and end time during which a deployment is to be in Running state on the designated days.
Repeats fieldChoose Daily if the policy should put the deployment in Running state every day during the designated start time through end time period. Choose Weekly and then choose specific days if the policy should put the deployment in Running state only on certain days during this time period.
Blockout Dates fields

Optionally configure blockout dates as follows, which are individual dates or date ranges on which the deployment remains suspended for 24 hours beginning at 12:00 a.m., regardless of the runtime schedule that you configured.

To add an individual blockout date, click DATE and then choose the date.

To add a date range, click Date Range and then choose the start date and end date of the range.

You can enter as many dates and date ranges as needed. To delete a date or date range entry, click the trash can icon in its Actions column.

Suspension Policy Guidelines

  • A suspension policy does not prevent you from performing manual suspend and resume operations on a deployment. For example, if a policy sets a deployment to suspend a 9:00 a.m. and resume at 5:00 p.m., you could manually resume the policy at 4:00 p.m.

  • By default, a suspension policy uses the time zone of the user that deploys the application using that suspension policy. In this way, no matter which time zone the application is physically running in, the suspension policy will be enforced according to the time zone of the user that launched the application.

Security Policies

A security policy is a policy that can contain ingress and egress rules and can be dynamically attached to a CloudCenter deployment.

Security policies are configured at the tenant level and can be associated with System Tags, the security policy is automatically selected and attached.

The Security tab enables you to create a security policy and add a list of firewall rules. The source and destinations of these rules could be IP CIDRs or other security policies.

The Security Policies page lists configured security policies and lets you perform the tasks described in the following table.

TaskDescription
Add a new security policy.

Click the New Security Policy link.

See Configuring a Security Policy for details.

Set permissions for a security  policy.

Choose Share from the dropdown list in the Actions column for the policy.

See Permission Control > Policy Permissions for details.

View information about a security policy.

You can view the following information for each policy:

  • Description – Optional description that was configured for the policy
  • Last Updated – Date and time that the policy was last updated
  • Share with Sub-tenants – Described in the Share with Sub-tenants section above.
  • Ports – Lists the open inbound and outbound ports that are configured for each security policy
  • Enable –  Identifies if this new security policy should be enabled for the associated resources.
View or update configurations for an existing security policy.

Choose Edit from the dropdown list in the Actions column for the policy.

The Edit page for the policy displays. See Configuring a Security Policy for a description of the fields that you can update. If you make updates, click the Save button on the Edit page to save your changes.

Delete an security policy.

Choose Delete from the dropdown list in the Actions column for the policy.

See Deleting a Security Policy for a description of the fields that you can update.

Enable or disable a security policy.

Turn on or off the Enable switch for the policy.

When a policy is disabled, future deployments cannot use it. The policy remains in effect for existing deployments.

Configuring a Security Policy

The CCM UI (Admin > Policies > Security) enables you to assign firewall rule sets when adding a security policy.

The following screenshot shows the Add a New Security Policy page.

Deleting a Security Policy

You cannot delete a security policy if the CCO is down or not reachable.

You can manually delete the security policy (as long as it not have any running job associated) from the Security policy page.

When you try to delete a security policy, the CloudCenter platform deletes the firewall rules on all configured CCOs.

  • If the CCOs are functional, then the CloudCenter platform attempts to delete the firewall rules on all configured CCOs.

  • If one of the configured CCOs is down or not reachable for any reason, delete the Cloud Region for this CCO to ensure that firewall rules on that particular CCO are skipped – If you delete a cloud region for a functional CCO, the CloudCenter platform skips firewall rules

  • If a CCO is already deleted, the CloudCenter platform does not attempt to delete the firewall rules on the deleted CCO.

Be sure to make the CCO functional or delete the cloud region whose CCO is not functional and attempt the deletion of the security policy again.

Azure Cloud Nuances

Due to the Azure limitation on the number of Security Groups, the Azure security group lifecycle is tied to an Instance – the security group is created when you create an instance is deleted when you delete the instance.



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