Policy & Governance

The Policy & Governance page in Firefly is where you define, manage, and review compliance policies for your cloud assets. This feature allows you to implement policy-as-code – automated rules that ensure your cloud configurations meet security, compliance, and best practice standards. Firefly's governance engine uses the Open Policy Agent (OPA) framework under the hood, and comes with a rich set of built-in rules plus the ability to add custom ones.

Overview of Policies

When you navigate to the Policy/Governance section, you'll typically see a table of policies. Each policy is essentially a rule that either passes or fails against each asset. Firefly provides dozens of Built-in Policies out-of-the-box. These cover common checks across categories such as Access Control, Encryption, Networking, Resource Management, Cost, etc. For example, built-in policies will check for things like "S3 buckets should have versioning enabled", "Databases should not be publicly accessible", "VMs should have a backup snapshot", or "Ensure no unused EBS volumes" – improving performance, security, or cost efficiency. These built-in rules are continuously updated by Firefly (they leverage the open-source KICS policy repository).

The table will list each policy with details like its category, severity, how many assets are violating it, and the compliance percentage. There's also an Insights column which may provide a recommendation or rationale (e.g. "Enable encryption to protect data at rest"), and a Notification column if alerts are enabled for that policy. The Compliance column shows the percentage of assets that are passing that policy check – effectively giving you a compliance score for that rule. For instance, a policy "No public S3 buckets" might show 98% compliance (meaning 98% of S3 buckets are private, 2% are public and thus violating).

Filtering & Organizing Policies

At the top of the governance page, you have filters to focus on specific sets of policies. You can filter by Frameworks, Categories, Providers, Severity, etc. Frameworks refers to compliance frameworks or standards – Firefly may group policies according to standards like CIS Benchmark, ISO27001, or internal company standards. For example, you could filter to "CIS AWS" to see all policies related to that framework. Category filter lets you show only cost policies, or only security policies, etc. You can also filter by cloud provider (to see just AWS-related policies vs GCP). This helps when you have many policies; you might only care about critical severity ones, for instance. There's also a quick filter for Violating Assets (to show only policies that currently have violations) and Enabled/Disabled (since you can turn policies on or off).

Creating & Managing Policies

To add a new policy, click "New Custom Policy" (or a similar button). Firefly will prompt you to define the rule. Key fields you'll fill in:

• Name – A descriptive name (e.g. "Ensure RDS Instances are Encrypted").

• Category – Choose an existing category like Security, Best Practices, Cost, etc., or create a new custom category to group your policy.

• Severity – Set the impact level (Info, Low, Medium, High, Critical). This helps prioritize and can tie into notifications (maybe you only page on high/critical).

• Scope – Select which data source (cloud) and asset type the policy applies to. For instance, you might scope it to AWS + S3 Bucket. (If you plan to use Firefly's AI policy suggestion, note that you should select only one data source and asset type for the AI to work well.)

• Policy Logic (Rego code) – Here you write the actual rule in Rego (the policy language). If you're comfortable with OPA Rego, you can write it directly using Firefly's provided input schema for that resource type (shown in the UI). For example, for an S3 bucket policy, the input schema shows the JSON fields available (like .publicAccess, .encryption, etc.) which you can use in your rule. Firefly even provides a Rego playground link for testing. If you're not a Rego expert, Firefly has an AI Policy Generator: you describe in plain English what you want (e.g. "S3 buckets must have encryption enabled"), and it will suggest Rego code for you.

• Evaluation/Test – Before saving, you can test the policy against current assets. Firefly's interface often has a "Evaluate" or "Test" button which will run your rule on some sample assets to see if it matches what you expect. If you get errors or no results, you may need to adjust your code (the UI will guide you to debug, like checking the input schema or trying the Rego playground with a sample asset).

Once created, the custom policy will appear in the list. Firefly will automatically evaluate it against all relevant resources and update the compliance stats. Managing policies is straightforward: you can enable/disable any policy (toggle it on or off, which controls whether Firefly is actively evaluating it). You can also edit a policy's code or details later if needed (via an "Edit" action). If you need to remove one, you can delete custom policies as well.

Viewing Violations & Taking Action

The governance table shows how many assets violate each policy (the Violating Assets count). You can click on that number or an action like "View Assets" to see exactly which assets are failing the policy. This will take you to a filtered Inventory view or a pop-up listing those assets. From there, you can drill into each asset to see details. Often, Firefly provides a quick remediation suggestion for each violation in the policy details – this might be shown as an Insight or when viewing the asset's Governance tab. For example, if an S3 bucket is unencrypted, the insight might say "Enable encryption by adding server_side_encryption configuration".

Firefly can assist in fixing violations. In some cases, you'll see a button like "Remediation" next to a policy or asset. Firefly's remediation feature can generate the code to correct the issue. For AWS assets, Firefly can create a snippet of Terraform or CLI commands that implement the required change (e.g. a Terraform resource block enabling encryption). By clicking "Remediation" on a violation, you might get a dialog with the exact steps or code to run to resolve it. You can copy those commands and run them in your environment to fix the configuration. This is particularly helpful – instead of just telling you what's wrong, Firefly tries to also provide the fix (akin to a security scanner that also gives you the patch). After applying a remediation, you would re-run Firefly's scan (it often updates automatically if event-driven) and see that the asset now passes the policy.

Additionally, Firefly integrates with external tracking tools for policy management. For instance, next to a policy or violation, you might have an option "Create Jira Ticket". If you use Jira or ServiceNow for ITSM, Firefly can raise an issue with the context of the violation (asset ID, what policy failed, etc.). This way, you can assign it to the responsible team member and track it to closure. This integration helps ensure policy violations are not ignored – they become actionable tasks in your normal workflow.

Compliance Reporting

Over time, the Governance page serves as your compliance dashboard. You can use it to report on how well the infrastructure complies with internal policies or external regulations. For each policy, the compliance % tells you where you stand. You might have a target to reach 100% on critical policies. Firefly's Frameworks filter, if configured with standards, can help you gauge compliance with, say, SOC2 requirements by grouping relevant policies. You can also export policy results if needed for audits.

Firefly's built-in policies and the ones you add essentially form a guardrail for day-to-day operations. They run continuously in the background (Firefly rescans periodically and on events, checking these policies). When something drifts out of compliance – e.g., someone creates a resource against policy – Firefly flags it immediately. This significantly reduces the risk of configuration sprawl and security holes.

A best practice when starting out is to review the list of built-in policies and enable those that matter to you (they might all be on by default, but you can choose to focus on some). Maybe start with high-severity ones (like open security groups, unencrypted DBs) and ensure those are clean. Then gradually enforce more policies (like cost-related or tagging policies). Also, write custom policies for any unique requirements in your organization – Firefly's AI can help if you're not sure how to encode them.

Remember to set up Notifications for policy violations if you want proactive alerts. In the Notifications settings, you can choose to be alerted when a new violation appears. For example, have Firefly send a Slack message if any Critical policy is violated on a production account. This way, governance is not just a periodic report but a real-time activity. Firefly even positions this as part of "Governance as Code" – automating cloud governance at scale alongside your version control and deployment processes.

In summary, the Policy & Governance page is your command center for cloud compliance. By leveraging built-in rules and customizing your own, you ensure your infrastructure is continuously checked against the rules that matter to your business. Firefly's integration of policy-as-code, combined with its remediation and ticketing capabilities, makes it much easier to enforce standards across multi-cloud environments. Over time, you should see your compliance percentages rise, fewer violations as teams become aware of policies, and an overall more secure and efficient cloud infrastructure.