About Flexera Policies
This section provides an overview of the following Flexera policy topics.
Policy Use Cases
Flexera developed a wide variety of built-in policies that provide high value with minimal effort on Day 1. You can simply select the policy you are interested in, customize it, and apply it to individual accounts or across multiple accounts to achieve your business outcomes. See the List of Flexera Policies.
In addition to the following examples, the policy engine supports writing custom policies to help customers achieve custom requirements and not be limited by what Flexera provides out of the box.
Cost
Increase cost visibility and management in your multi-cloud world and take appropriate actions to run an efficient infrastructure.
|
•
|
Identify where you are wasting spend and realize immediate savings |
|
•
|
Collaborate to reduce future cloud costs |
|
•
|
Use tagging as a foundation for ongoing cost management |
|
•
|
Automate waste prevention |
Security
Gain visibility and control across all your public and/or private cloud environments with our security policies. Improve security across your applications, data, and associated infrastructure by finding security vulnerabilities before your customers do.
|
•
|
Secure public storage buckets |
|
•
|
Take control of your security groups |
|
•
|
Monitor and secure IAM access |
Operational
Save valuable human time and investment by automating everyday IT operations. Running an automated and efficient cloud infrastructure frees up expensive resources on high ROI projects like scaling, growth, and deliver value faster than anyone else.
|
•
|
Reduce waste by putting instances on schedule |
|
•
|
Put automatic key rotation to avoid downtime |
Compliance
Enterprises typically have multiple compliance requirements but struggle to automate them which leads to downtime as well as resource waste. By having a strong compliance strategy but also ability to quickly automate it provides peace of mind and avoids business interruption.
|
•
|
Ensure comprehensive tagging strategy |
|
•
|
Write custom policies for HIPAA, GDPR, PCI, and more |
Policy Actions
Policy Engine leverages our multi-cloud orchestration platform written in Cloud Workflow Language that allows managing entire applications running on the cloud. Actions can be defined that help remediate policy incidents or that trigger other automation to report on incidents.
The sequence of actions that occur when an incident is detected is defined in the Policy Template. At any point in the sequence, Manual Approval Steps can be inserted that require an authorized user to press an Approve button in the UI (or equivalent API call) before the sequence is resumed. Actions can also be Run Manually. When applying a policy, the policy manager can choose to skip all defined approval steps so that the action sequence runs fully automated immediately when an incident is detected. In this case the incident details will show that the approval steps were skipped.
Policy Action Examples
|
•
|
Change (downsize) instances |
|
•
|
Add/Terminate/Delete resources (for example, Unattached volumes, old snapshots) |
|
•
|
Migrate between storage classes |
|
•
|
Slack and Email Notifications |
|
•
|
Running Operational Runlists |
|
•
|
Retrieving and analyzing metrics data |
|
•
|
Sending requests to external applications |
Basic Concepts
The following basic policy concepts are covered in this section:
Policy Template
Open source policy definition, written in powerful Policy Template Language, that defines the blueprint of a Policy. It specifies input parameters, conditions, and actions the policy will take when it is triggered. You can use built-in policy templates from Flexera as is or customize the source code to create your own custom policy. Policy Template can be published to the Catalog to make it visible to the entire organization.
Applied Policy
A running policy that has been applied from a policy template. It inherits all the properties of the policy template. One policy template can be applied as many times as needed with different input parameters. For example, you could apply a policy that looks for unattached volumes to development accounts and production accounts with different parameters and resolution actions. In development accounts, you could configure the applied policy to automatically delete unattached volumes after 3 days, while in the production accounts, you could simply send an email alert.
Credentials
Important:Credentials can be managed only by users with the Manage cloud role on the Organization, but all users that can apply policies have access to use credentials while applying a policy. For complete descriptions of each role available in Flexera One, see Flexera One Roles.
To gather information and, in some cases, take action, policies need to be able to reach out to other APIs. While some policies interact only with other Flexera APIs, many policies interact directly with service provider APIs. In these cases, the system must have credentials for those APIs. The Credentials page provides a central location to enter, manage, and update credentials that can be used by policies.
Incident
When the conditions of the applied policy are met, an incident is created. It contains all the information about why the policy was triggered and the current status. One applied policy can have more than 1 incident. Incidents can be in one of the following states:
|
•
|
Active - one or more conditions were found to be true during the policy check (this state is called triggered in the API) |
|
•
|
Resolved - the conditions that created this incident no longer exist, or the resolve_incident function was called (see the Syntax section of the Policy Template Language) |
|
•
|
Terminated - the applied policy was terminated while the incident was active |
Incidents that are not actionable (they are terminated or resolved with no pending actions) are archived after 30 days and available only via the API.
Registering a Credential
Many policies require cloud credentials in order to gather data and perform remediation actions - for these policies, a credential must be registered with Flexera before applying the policy. Registering a credential generally requires administrator privileges in both the API provider as well as in Flexera. For details, see Managing Credentials for Policy Access to External Systems.
Applying a Policy
All Flexera policies are published to the Policy Catalog where users can browse for policies that meet their needs. In addition to Flexera policies, your organization can develop and publish their own policies to the catalog for unique use cases. The policies are organized by category and can be searched by using the Filter bar at the top of the page.
Once you've found a policy that is relevant, click through to the README to read about the details of how the policy works and what actions are supported. To put a policy in place, click the Apply button to configure the policy for your environment. Each policy may contain different configuration items based on what the policy does, but all policies have some common configuration parameters (see Common Policy Configuration Options). Policies can be run in test mode first to ensure no changes are made to the environment (see Common Policy Configuration Options), and then later edited to remove test mode (see Automation User Interface Overview) and provide automated resolution actions.
How Policies Work
Policies work by reaching out to other systems via API calls to gather information,
Managing Applied Policies
Every policy that is currently applied in an account is listed in the Applied Policies page. If you have access to more than one account, use the account picker in the top of the page to change accounts. Clicking on a policy will show the details of the policy, including:
|
•
|
When it was applied, when it last ran, and when the next run will be |
|
•
|
Who applied the policy and what configuration parameters they set |
|
•
|
The original template name, severity, and category of the policy |
|
•
|
Any incidents that are currently active with this policy |
To stop a policy, click the Terminate button at the bottom of the page. Doing so will remove this policy and any related incidents from the system.
If there are any active incidents for this policy, click the incident link to view detailed information about the incident.
Updating Applied Policies
Common Policy Configuration Options can be updated for an applied policy from the Applied Policies page by selecting Organization Summary from the account selector drop down, choosing the policy to update and clicking the Edit button. Updated policies will immediately evaluate after updating. For policies with no changes to frequency, an update will not effect their normal evaluation schedule.
Handling Incidents
An incident is created when one or more resources fail the check that the policy performs. To see incidents, navigate to the Automation menu and click Incidents or click through from an applied policy. The Incidents screen includes the following tabs:
|
•
|
Incident Details shows how many resources failed the check and allows for the manual running of actions. |
|
•
|
Action Log indicates whether any incidents have pending approvals before mitigation actions are run, and displays the last 50 actions that have been taken on the incident. |
|
•
|
Policy Details displays details about the policy. |
Selecting an incident will show the details of the incident -- each policy has its own definition of what information to show as part of an incident. Many policies will have some kind of table that displays information about each of the resources that has violated the policy. When a table is present, you can export the data to CSV to work with locally.
In addition to resource information, policies frequently define escalation actions that occur when an incident is detected. These actions vary by policy, but are extremely flexible and can range from simply sending an email to taking an orchestrated set of actions to attempt to remediate the incident. The Actions panel on the right side of the incident display shows the action sequence and status of each action.
Incidents can involve one of the following actions:
Manual Approval Steps
Important:Manually approving or denying a policy using the Deny or Approve buttons requires the Approve policies role. For complete descriptions of each role available in Flexera One, see Flexera One Roles.
As part of an action sequence, a policy can define a manual approval step, which will pause the action sequence until the action is approved or denied. In such cases, you will see an action in the Pending state. If the action is denied, the action sequence is terminated. If the action is approved, the action sequence continues to the next action.
If the Skip Approvals checkbox was selected when applying the policy (see Common Policy Configuration Options) then all approvals are automatically approved by the system, and the state for each approval will show Skipped.
Important:Treat this Skip Approvals option with caution as it could remove or change resource you wish not to change. Do no use this option on critical cloud resources such as those in a production or other critical environments.
Note:This Skip Approvals option isn't available for policy templates with the Automatic Actions field
Run Manually
Escalation and resolution actions can be manually run using Run Action. Escalations must be run before an incident is resolved and resolutions afterwards.
Select Actions
In the case of incidents for which multiple resources have failed validation, actions can be run on any individual or combination of those failed resources. The checkbox above the list of resources can be used to select or deselect all resources. Actions can also be run on individual actions by the drop-down menu to the right of the screen.
Many policies from the Flexera Policy Catalog support the Select Actions feature. These policies also have the option to run one or more actions automatically. When the Automatic Action field includes the action(s), those actions are run automatically on all resources when the incident is created. This functions similarly to the Manual Approval Steps Skip Approvals. See the policy template README for more details.
Important:Treat this Skip Approvals option with caution as it could remove or change resource you wish not to change. Do no use this option on critical cloud resources such as those in a production or other critical environments.
Automation Dashboard
The Automation dashboard provides an overview of all of the policy information in the selected account. It includes a summary of the number of policies running, open incidents, actions awaiting approval, and more. This is a great page to bookmark and start with when you are managing policies on a day-to-day basis. From the Dashboards menu in Flexera One, click Automation to access the Automation dashboard.
Policy Lifecycle
An applied policy represents policy template code that is evaluated on a fixed schedule that is configured by the user applying the policy. The schedule can range from 15 minutes to monthly depending on the needs and requirements of the policy and will run on that schedule until terminated by a user.
Each evaluation of a given policy is stateless -- all data needed must be fetched every iteration and processed as needed.
Each applied policy runs in the context of a single Flexera One account. The policy user interface allows for applying a policy across multiple accounts, in which case an applied policy is created in each account selected.
Policy evaluation consists of a series of steps:
Permissions Check
Permissions are checked if an optional Permissions block is supplied. If the user doesn't have sufficient permissions to take the actions specified, the policy is not applied. These permission checks are currently limited to user roles and actions within Flexera One.
Data Retrieval and Transformation
Data retrieval is accomplished using the API Data With Datasources and resource references. A policy can have any number of such references, each of which will typically correspond to a single API request to Flexera One or an external API.
If a policy needs to act on data from multiple API calls, datasources may be chained together (see Chaining Datasources) to have one feed into another. The Policy Debug Log will list API requests as they happen as well as a snippet of the data downloaded.
Validation
Once all data has been gathered, the validations defined in the policy block are evaluated. Validations consist of a series of checks on the data. Any items failing those checks are gathered together as violation data. Each validate and validate_each statement occurs independently of the others and can produce 1 “incident”. Multiple validate statements can therefore produce multiple incidents. A validate or validate_each statement may have multiple check statements. The first failed check will result in that data being added as a violation.
If all checks pass and there is no violation data, then one of two things can happen. If no incident exists, nothing will happen and no incident will be generated. If an incident currently exists in a triggered state, it will proceed to a resolved state and any resolution actions defined will be run.
If there is violation data, that data is acted on by any escalate actions defined on the policy.
Incident Actions
In the case where a violation is detected and an incident already exists, the system evaluates the whole of the violation information to determine if any piece of data in the violation has changed, and if so then the incident actions defined in the escalation section will be run. This means that if an existing incident is updated with new violation data, the escalation actions such as email, run, or request_approval will be run again as if it were created for the first time. Actions can be run manually on some or all items in violation with run_action.
Escalations will proceed until they come to a stopping point. This is a either a manual action such an approval_request, an error, or because all actions have finished. If multiple escalate fields are given, they will be evaluated in parallel and the status of each one gathered separately. The incident will continue to exist in a triggered state until the underlying conditions which triggered it change.
Termination
When an applied policy is terminated, any incidents are immediately moved to a terminated state. Any cloud workflow actions defined in run statements will run to completion unless manually aborted in the Cloud Workflow console. No additional escalation or resolution actions will be taken.