LogoLogo
  • Welcome to Firefly Documentation
  • Introduction
    • What is Firefly?
    • Who is Firefly for?
    • Why use Firefly?
    • Terminology (Glossary)
  • Key Features
    • Infrastructure-as-Code Automation
    • Cloud Asset Inventory
    • Drift Detection & Remediation
    • Policy-as-Code for Compliance & Governance
    • Cost Visibility & Optimization
    • AI Assistant
    • ChatOps Integration
  • Getting Started
    • Account Setup & Onboarding
    • Connecting Cloud Accounts
    • UI Walkthrough & Navigation
    • First Steps in Firefly
  • Detailed Guides
    • Dashboard Overview
    • Cloud Asset Inventory
      • Remediating Drifts
      • Deleting Assets
      • Creating IaC-Ignore Rules
      • Creating Exclude-Drift Rules
    • Policy & Governance
      • Creating Policy-as-Code Governance Rules
      • Remediating Policy Violations
    • Workflows & Guardrails
      • Creating Workflows
      • Creating Guardrail Rules
    • Codification
    • Self-Service
    • IaC Explorer
    • Event Center
    • Backup and Disaster Recovery
    • Notifications
    • User Management
    • SSO Configuration
  • Integrations
    • Integrations Overview
    • Integrating Data Sources
      • AWS
      • Azure
      • Google Cloud
      • Kubernetes
      • Akamai
      • Datadog
      • New Relic
      • Okta
      • GitHub
      • Cloudflare
      • NS1
      • PagerDuty
      • MongoDB Atlas
      • HashiCorp Vault
    • Integrating IaC Remote State
      • Terraform Cloud
      • Google Cloud Storage
      • env0
      • HashiCorp Consul
      • Firefly States Redactor
    • Integrating Version Control
      • GitHub
      • GitLab
      • Azure DevOps
      • CodeCommit
      • Bitbucket
    • Integrating Notifications
      • Slack
      • Microsoft Teams
      • PagerDuty
      • Opsgenie
      • Torq
      • Webex
      • Google Chat
      • Webhook
    • Integrating Project Management
      • Jira
      • ServiceNow
    • Integrating Workflows with CI/CD
    • Integrating Backstage
    • Integrating MCP
  • Use Cases & Best Practices
    • Cloud Governance & Visibility
    • Cost Optimization Strategies
    • Compliance and Security Best Practices
    • Infrastructure Automation & Self-Service
    • Best Practices and Implementation Tips
  • Analytics & Reporting
    • Analytics Dashboard Overview
    • Using Analytics for Improvement
    • Exporting and Sharing Reports
    • Analytics Security and Privacy
  • Code Snippets & Examples
    • Terraform Snippet for an AWS EC2 Instance (Codified via Firefly)
    • Example Rego Policy (OPA) for a Custom Rule
    • GitHub Actions Workflow YAML for Firefly Integration
    • JSON Output Example: Exporting Inventory
  • Troubleshooting & FAQs
    • Common Issues and Solutions
    • FAQs
  • General Information
    • Firefly API
      • Authentication
      • Inventory
      • Codification
      • Workflows
      • Self-Service
      • Policy & Governance
      • IaC Explorer
      • Event Center
      • Backup & Disaster Recovery
      • Notifications
      • Integrations
      • Identity & Access Management
    • Security & Compliance
    • Pricing Tiers & Add-ons
    • Contacting Support
Powered by GitBook
On this page
  • RBAC (Role-Based Access Control)
  • Admin Role
  • Viewer Role
  • Differences in permissions
  • Future RBAC expansion
  • Creating Firefly Key-Pair for API and FireflyCI
  • Using the API Key with FireflyCI

Was this helpful?

  1. Detailed Guides

User Management

RBAC (Role-Based Access Control)

Firefly provides a role-based access control system to manage user permissions within the platform. RBAC in Firefly is currently straightforward, with two primary roles available: Admin and Viewer (Manage user roles | Firefly Documentation Portal). Each role comes with a different level of access and capabilities in the Firefly platform.

Admin Role

Admin users have full access to the Firefly platform. They can manage integrations, view and modify all assets, and perform codification and remediation actions. Crucially, an Admin can manage user accounts and settings. For example, Admins are the ones who can invite new users to the workspace and assign roles (either Admin or Viewer) to them (Manage user roles | Firefly Documentation Portal). Admins can also create API key pairs, set up integrations/providers, define ignore rules, exclude drifts, configure notifications, and generally make any changes in the Firefly environment. Essentially, this role is for those who need control over configuration and governance in Firefly.

Viewer Role

Viewers have read-only access. A user with the Viewer role can log in to Firefly and see the inventory of assets, their IaC status, drifts, insights, etc., but cannot make changes that affect the environment's configuration. Viewers cannot onboard new integrations, cannot invite other users, and cannot initiate codification or other write actions. This role is ideal for team members who need visibility (for example, auditors, developers, or stakeholders who just want to monitor infrastructure state) without the ability to alter settings. The Viewer is essentially a consumption role – they can consume the data and dashboards but not modify resources or settings.

Differences in permissions

In summary, the Admin role encompasses all permissions (including those of Viewer plus administrative actions), while the Viewer role is restricted to read-only activities. For instance, if there's a button to "Fix Drift" or "Codify" an asset in the UI, a Viewer would likely not have access to execute that, whereas an Admin would. Similarly, only Admins see the settings pages for things like user management, integrations, API keys, guardrails, etc., whereas Viewers might not even see those options in the interface or will be blocked from using them.

Currently, these two roles apply to the entire workspace (account) in Firefly. Granular RBAC (such as limiting a user's access to only specific cloud accounts or projects) is not yet available in the platform (FAQ | Firefly Documentation Portal). Every user is either an Admin or Viewer for the whole environment. For example, you cannot yet create a role that only allows someone to view a single cloud integration and nothing else – they would need to be a Viewer (and see everything) or not have access at all. Firefly's FAQ notes that full RBAC capabilities (more fine-grained access control) are on the roadmap but not currently implemented (FAQ | Firefly Documentation Portal).

Future RBAC expansion

Firefly intends to expand its RBAC system in the future. While today you are limited to just Admin and Viewer roles, future updates may introduce more roles or permission settings. This could include roles with scoped access (e.g., project-specific viewers), custom roles, or integration-specific permissions, to cater to enterprise needs for more nuanced access control. As of now, if you require a user to have limited access, the workaround is to use the Viewer role and trust that they only engage with the relevant data, or not invite them until more control is available. Keep an eye on Firefly's updates for more advanced RBAC features as the platform evolves.

Creating Firefly Key-Pair for API and FireflyCI

To use Firefly's API or integrate with FireflyCI (Firefly's CI/CD integration), you need to generate an API key pair (Access Key and Secret Key) for authentication. Follow these steps to create a new key pair and use it securely:

  1. Navigate to the Key Pair settings: In the Firefly web console, go to Settings > Users (Creating a key pair | Firefly Documentation Portal).

  2. Create a new key pair: Click "Create Key Pair." Firefly will generate an Access Key and Secret Key for you (Creating a key pair | Firefly Documentation Portal).

  3. Copy the keys: Once generated, copy the Access Key and Secret Key. They will be shown only once, so make sure to save them immediately (Creating a key pair | Firefly Documentation Portal).

  4. Store the keys securely: Save your key pair in a secure place (e.g. a password manager or secrets vault). Treat the Secret Key like a password – keep it confidential (Creating a key pair | Firefly Documentation Portal).

  5. Close the dialog: After copying your credentials, click Close to finish the key pair creation process (Creating a key pair | Firefly Documentation Portal).

Using the API Key with FireflyCI

After obtaining your keys, you can use them in FireflyCI to authenticate. In your CI pipeline configuration, add the Access Key and Secret Key as environment variables (for example, in GitHub Actions or other CI tools). Name the variables FIREFLY_ACCESS_KEY and FIREFLY_SECRET_KEY, and set their values to the keys you generated (IaC Automation in Action - DIY CI Pipelines without the Pain). For security, store them as encrypted secrets in your CI system and reference them in the pipeline. For example, in a GitHub Actions workflow you might include:

PreviousNotificationsNextSSO Configuration

Last updated 1 month ago

Was this helpful?