Event Center

Firefly's Event Center is the central place to track and audit all infrastructure changes (mutation events) detected by the platform. It provides a timeline-based view of what's happening in your cloud – essentially an activity feed for your infrastructure. This is crucial for visibility and compliance, as it allows cloud owners to see who changed what and when.

Overview of the Event Center

The Event Center presents a chronological log of events (or "asset mutations") across your integrated cloud accounts and IaC repositories. Each event corresponds to a change in an asset's state. The view is typically a timeline or table where each entry includes details like: timestamp, asset affected, type of change, source of change, and the actor (who made the change, if known).

For example, you might see entries such as: "2025-03-01 14:32 UTC – EC2 Instance i-12345 changed: Security Group modified – by Alice (IAM User)" or "2025-03-01 15:10 UTC – Terraform Stack network-prod – Pull Request merged (IaC update) by Bob". This gives you a unified history of infrastructure changes across both ClickOps (manual changes) and IaC-driven changes.

The Event Center is updated in near real-time. Firefly listens to cloud events (like AWS CloudTrail, Azure Activity Logs, etc.) and IaC tool events. When a change occurs, Firefly records it as an event in this feed. This enables rapid detection – you don't have to wait for a daily scan; you can see changes as they happen (or shortly thereafter). You can filter the events by cloud account, resource type, severity, or timeframe to drill down.

Overall, think of the Event Center as an audit log for your cloud: it's where you go to answer "What happened recently in my infrastructure?".

Auditing ClickOps and Mutation Events

One of the primary uses of the Event Center is to audit ClickOps changes. Because Firefly tracks configuration drift and unmanaged changes, any time someone modifies a resource outside of IaC, an event will appear. These could be flagged as "unmanaged change" or "drift detected." For instance, if a user manually opens the AWS console and changes an S3 bucket setting, Firefly (via cloud events) will log a mutation event noting that the bucket's configuration was altered. In the Event Center, such an entry might be highlighted (since unmanaged changes are often important to address).

By regularly reviewing these events, you can catch unauthorized or out-of-process changes. Firefly essentially helps answer: "Was there any ClickOps activity I need to be aware of?" Every mutation event includes as much detail as possible, so you know the scope of the change. This includes which resource attributes changed (when available) – e.g., a tag added, a firewall rule changed, etc. Firefly's deep change tracking can even provide diffs for changes: you may see a before vs. after value for the resource's configuration, much like a code diff, which is incredibly useful for understanding exactly what changed.

In addition to manual changes, automated changes are also logged. If a Terraform apply added 5 new resources, you'll see 5 events for those creations (possibly grouped together or noted as part of a IaC deployment). If a CI/CD pipeline or an auto-scaling event in the cloud occurred, those show up too. This comprehensive capture of events means no change goes unnoticed – whether it's an admin tweaking something at 2 AM, or an automated script cleaning up resources.

Using the Event Center, you can audit your infrastructure in a continuous manner. Many teams review the Event Center daily or set up alerts (see next section) to know when important changes happen. It helps enforce that all changes are either expected (via code) or, if they are unexpected manual changes, they can be quickly remediated (for example, by codifying them or reverting them).

Ownership Tracking (Who Made the Change)

Firefly's Event Center also emphasizes ownership information for changes. Each event ties back to a user or process that caused it, whenever possible. If the change came from cloud activity, Firefly pulls the actor from the cloud's audit logs. For example, on AWS, CloudTrail provides the IAM user or role that executed the action; Firefly will display that in the event details (e.g., "by IAM User [e-mail]" or "by AWS CloudFormation role XYZ"). On Azure or GCP, similarly, the initiating user/service is recorded.

If the change is IaC-driven via Git, Firefly may show the commit author or pipeline user. For instance, if a pull request was merged on GitHub by Bob, and that triggered a Terraform apply, the Event Center might log the change as coming from GitHub/Bob or from your CI service account. This way, you have an audit trail of who is responsible for each change. This is vital for governance and post-incident analysis – you can quickly reach out to the person or team responsible if a change had unintended consequences.

There may be cases where the "who" is not immediately clear (for example, if using an assumed role with no distinguishable user). Firefly will still log the role or the service that made the change. Additionally, Firefly's integration with identity providers or single sign-on might allow it to map cloud role names to actual people or team names in your organization (for easier recognition).

The Event Center can be used to answer questions like: "Who deleted this resource?", "Which engineer applied this change?", or "When did this configuration last change and who was involved?". This eliminates a lot of guesswork and manual digging through CloudTrail logs or CI logs – Firefly consolidates it for you.

Integration with Logging & Alerting

To make sure you don't miss critical events, Firefly allows integration of the Event Center with external logging and alerting systems. In the Notifications settings, you can configure Firefly to send change events to your preferred tools. Some popular integrations include:

• Slack and Microsoft Teams: Firefly can send real-time alerts to chat channels. For example, whenever a high-severity change occurs (like an unmanaged deletion of a production resource), a message can be posted to your Slack channel. The message typically contains the resource name, what changed, and a link back to Firefly for details. This way, your team can discuss or respond immediately. You can configure what level of events trigger a notification (e.g., all drift events, or only failures, etc.).

• Opsgenie, PagerDuty, etc.: If you use incident management tools, Firefly can create alerts there. For instance, a policy violation or a huge drift could trigger a PagerDuty incident if you configure it. This is useful for on-call engineers to be paged for critical infra changes that require attention.

• Webhooks and SIEM: Firefly supports generic webhooks, allowing you to send event data to any HTTP endpoint. This means you can integrate with SIEM (Security Information and Event Management) systems or logging pipelines. For example, you could send all Firefly events to Splunk, Elastic, or Datadog for long-term analysis and correlation with other logs. Many teams pipe Firefly's audit log into their central log management to satisfy compliance requirements (retaining change history for X days, etc.).

• Email Notifications: Although not explicitly mentioned, it's common for such platforms to allow email alerts for certain events. If Firefly supports it, you could get an email summary for daily changes or instant emails for critical issues.

To set up these integrations, go to Settings > Notifications in Firefly, and choose the integrations you want (Slack, Teams, Webhook, etc.). You'll authenticate or provide the webhook URL as needed. Once set up, Firefly will push events as they occur. You can fine-tune which events trigger outbound notifications by severity/type to avoid noise.

Using Event Data: Beyond real-time alerts, the Event Center's data can be exported or queried. If needed, you can download a log of events or use Firefly's API to fetch event history for external analysis. This is useful for periodic audits or feeding data into compliance reports. For example, you might generate a monthly report of all changes in the production environment and highlight how many were via IaC vs manual – demonstrating improved infrastructure control over time.

In summary, the Event Center is your single source of truth for infrastructure changes. By leveraging it, you gain complete visibility into your cloud's evolution, can attribute changes to the right people, and integrate this knowledge into your ops workflows (through alerts and logs). It turns chaotic change management into an organized, auditable process, which is key for both reliability and security.