FAQs

In this section, we address common questions and issues that users might encounter while using Firefly | Manage Your Cloud with Infrastructure-as-Code. If you run into a problem, there's a good chance it's covered below. The FAQ is organized by topic: general usage, integration issues, feature behavior, security concerns, and licensing/support.

General Usage

Q: How can I grant a new user access to Firefly and what level should I give? A: In Firefly:

• Invite the user via Settings > Users (enter email, pick role Admin or Viewer).

• Admin vs Viewer: Admin can integrate new sources, manage settings, codify/delete resources, etc. Viewer can see everything (inventory, violations) but not perform actions that change things or alter settings.

• For most developers or auditors who just need to see data, Viewer is appropriate. For DevOps/SRE who will actively manage infrastructure through Firefly (codifying, fixing drift, approving guardrails), Admin might be needed.

• There are currently only two roles. If you need more granular control (like someone can manage some integrations but not others), that's not yet built out – you'd have to either trust them as Admin or restrict to viewer and handle those tasks centrally.

• If the user did not receive an invite email (common issue), check that the email is correct and not in spam. Resend invite if needed. They can also go to the Firefly login page and use "Forgot password" with that email, sometimes that triggers setting a password if invite link failed.

Q: Where can I get help if I encounter a problem not covered here? A: Several resources:

• Firefly Documentation: (You're likely reading it on GitBook). The docs have specific how-to guides and deep-dives – use the search function for keywords.

• Community/Support Forum: Firefly might have a community Slack or forum where you can ask questions and see if others had similar issues.

• Direct Support: If you have a support contract or during trial, you can email Firefly support ([email protected] or via the in-app chat if available). Provide as much detail as possible (screenshots, asset IDs, timestamps, etc.).

• Contacting Firefly Support Page: In the docs, there is usually a section on contacting support with instructions on what info to include (version, org ID, etc.).

• Updates: It's possible your issue is fixed in a newer version of Firefly – make sure you're on the latest (if Firefly is SaaS, they update it automatically, but if on-prem, apply the latest patch). Check the release notes for bug fixes related to your problem.

Feature Behavior

Q: I created a new .tfstate (Terraform state) file in my cloud storage, but Firefly isn't marking those resources as codified. A: Firefly might not automatically know about new state files unless told:

• For AWS, if you enabled Auto-discovery on integration, Firefly scans S3 for .tfstate files daily. If urgent, you can manually trigger the S3 scan via the integration settings.

• For GCP, if you stored states in GCS, ensure you integrated that bucket under "Integrate remote states > GCS" in Firefly.

• Make sure the state file's resources actually map to the same cloud account that Firefly is scanning. Firefly correlates by resource IDs; if the state is from another account or environment not integrated, it won't match.

• If all set and still not seeing it, check Firefly's Discovery Status (some integrations have a sub-page showing last scan time and results, e.g., "AWS Discovery Status" might list discovered state files).

• Ultimately, if needed, you can explicitly integrate the remote state via Firefly's Integrations (there are options for Terraform Cloud, Terraform Enterprise, etc., which will feed those known states in).

Q: I have duplicate resources showing up in Inventory. Why could that be? A: Duplicates can happen if:

• The same resource is integrated via two paths. For example, if you integrated an AWS account normally, and also integrated the same Terraform state that manages it via Terraform Cloud integration, Firefly might list the resource twice (once from cloud scan, once from state). Firefly usually de-duplicates by matching IDs, but if those IDs are slightly different formats or if one integration lacks the ID, duplicates appear.

• Another scenario: a resource moved from one stack to another in code but Firefly hasn't caught up (so temporarily it shows under both old and new).

• Solution: Check if the duplicate entries have slight differences (maybe one has IaC Stack "Terraform Cloud run X" and another "AWS direct"). If so, you might remove one integration to avoid double tracking. Firefly is supposed to merge them, but if not, consult support – they might adjust how they correlate the data.

• If it's a scenario of resource ID changes (like some Azure resources have different IDs via API vs portal), Firefly might treat them separately. In such niche cases, again contacting support with details helps.

• Usually, duplicates are rare. A quick fix can be to force a rescan and ensure all integrations (cloud and IaC) are updated. Firefly might then realize they're the same resource and merge.

Security Concerns

Q: What are the security implications of Firefly having read access to my cloud? A: Firefly is designed to be read-only in your cloud accounts. By using least-privilege IAM roles, it should not be able to alter any infrastructure on its own (unless you explicitly allow actions like deletion or adding tags as part of some automation via codify, and even those usually go through your pipelines or via assumed roles when you trigger them).

• All data Firefly reads (resource configurations, tags, etc.) is stored in Firefly's system (likely encrypted at rest). Check the Firefly security documentation for details on data handling – for instance, secrets like keys are not fetched, only metadata.

• If you use the AI features, consider that descriptions of your infrastructure are sent to an AI model (OpenAI or similar). Firefly likely uses that in a secure way, but avoid inputting highly sensitive information verbatim (e.g., don't paste secret keys into the AI prompt). The AI usage policy from Firefly should state that they don't retain your specific data beyond the session, etc.

• Ensure that Integration Keys (like API keys for Slack, PagerDuty, etc.) are treated like secrets. Firefly stores them to send notifications. If you suspect any compromise, you can rotate those keys both in the external service and update Firefly's stored key.

• Principle of Least Privilege: The IAM role you create for Firefly doesn't need to read your data, only configurations. For example, Firefly will know a bucket exists and its settings, but not the objects inside it. It reads security group rules but not the traffic going through. This limits exposure. If you have extremely sensitive contexts (say government classified), you might run Firefly in a more isolated way or on-prem with even stricter scopes, but generally Firefly has been vetted for enterprise security.

• Penetration Testing: If concerned, ask Firefly for any pen test reports or compliance certifications (they might have SOC2 for their service). It's reasonable due diligence.

Licensing and Support

Q: How is Firefly licensed and what if I hit asset limits? A: Firefly's licensing often is based on number of assets under management or number of cloud accounts, etc. Common questions:

• If you approach your asset tier limit, Firefly will likely notify you (either via account team or an in-app notice). It won't immediately stop working, but you should discuss upgrading the plan. Some features might be rate-limited if severely over the limit.

• Unused assets (deleted ones) don't count once they're gone. But ghost assets might still count if they remain in inventory. Clean them up if you're near limits.

• For trial versions, you may have a time limit or asset cap. In that case, integrate what's most important first to evaluate. You can always integrate more later after licensing.

• If you need to add, say, another 1000 assets and aren't sure about license, reach out to Firefly support or your account manager – they can often grant a temporary extension or quote an upgrade.

• Best Practice: Regularly audit what Firefly is managing to ensure you're within your expected range. If you remove a cloud account or project, also remove it from Firefly to free up license counts and avoid confusion.

Firefly Workflows FAQ

Q: What is Firefly Workflows? A: Firefly Workflows is a powerful tool for deploying Terraform within CI/CD pipelines. It streamlines deployment processes, offering an intuitive wizard interface to automate Terraform code deployment. Each workflow corresponds to a workspace, simplifying the deployment of resources. Additionally, Firefly Workflows provides visualization and monitoring features, enhancing deployment efficiency and visibility.

Q: When should I create a new workflow in Firefly? A: Creating a new workflow is suitable when you need to establish a dedicated deployment process for a specific project or task, simplifying CI/CD pipeline setup and management.

Q: How do I create a Firefly workflow? A: Use the Firefly wizard to automate Terraform deployment by creating a workflow within your CI/CD pipeline, with each workflow corresponding to a workspace.

Q: How do I integrate Firefly into an existing CI pipeline? A: Firefly provides Docker-based integration for existing Terraform deployment pipelines. Authentication is required, and deployment triggers are set up between terraform plan and terraform apply. To integrate Firefly with your existing CI pipeline, follow the procedure outlined in the documentation. You can also view the workflows examples template on a wide variety of CI tools.

Q: What are the system requirements for using Firefly Workflows? A: Firefly Workflows require a compatible CI/CD environment with support for Docker and Terraform/OpenTofu.

Q: Can Firefly Workflows integrate with other CI/CD tools apart from the ones mentioned in the documentation? A: Yes, Firefly Workflows can integrate with all CI/CD tools. Firefly provides a Docker-based solution that can work on any CI/CD tool.

Q: Are there any limitations on the size or complexity of Terraform projects that Firefly Workflows can handle? A: Firefly Workflows are designed to accommodate Terraform projects of varying sizes and complexity levels. There are no strict limitations imposed by Firefly Workflows.

Q: Do Firefly Workflows support multi-cloud deployments? A: Yes, Firefly Workflows support multi-cloud deployments, allowing you to manage infrastructure across multiple cloud providers within a unified workflow.

Q: How do Firefly Workflows handle state management and synchronization across multiple environments? A: Firefly Workflows leverage Terraform's state management features to track and synchronize infrastructure state across multiple environments. Each workspace within Firefly corresponds to a Terraform workspace, enabling isolation and management of state files for different environments.

Q: Can Firefly Managed Workflows automatically trigger deployments based on specific events or conditions? A: Yes, Firefly managed Workflows can automatically trigger deployments based on specific events or conditions. When you create a pull request (PR), Firefly initiates a Terraform plan, which provides insights into the changes to be applied to the infrastructure. After merging the PR into the default branch, Firefly triggers the terraform apply process, which applies the planned changes to the infrastructure.

Q: How do Firefly Workflows ensure the security of sensitive data? A: Firefly Workflows prioritize the security of sensitive data. Before transmitting any data to Firefly's servers, sensitive information is meticulously redacted to prevent unauthorized access or exposure. This ensures that sensitive data remains protected throughout the deployment process.

Q: Do Firefly Workflows provide any built-in monitoring or alerting capabilities for deployments? A: Firefly is currently in the process of developing monitoring and alerting functionalities for deployments and will be incorporated into Firefly Workflows in the near future. Stay tuned for further updates on the integration of monitoring and alerting capabilities within the platform.

Q: Is there a limit to the number of workspaces or workflows that can be created within Firefly Workflows? A: Firefly Workflows do not impose strict limits on the number of workspaces or workflows that can be created within the platform. You can create and manage multiple workspaces and workflows to accommodate diverse projects, environments, and deployment scenarios effectively.

Q: Is there a way to track and visualize the progress of deployments across multiple environments in Firefly Workflows? A: Yes, Firefly Workflows provide tools and dashboards for tracking and visualizing the progress of deployments across multiple environments in real-time. You can view deployment status, execution logs, resource changes, and pipeline metrics using integrated monitoring and visualization features within the Firefly Workflows dashboard.

Q: Do I need to provide Firefly Workflows with my cloud credentials? A: No, Firefly Workflows do not require you to provide your cloud credentials. Firefly prioritizes security and does not handle or store your cloud credentials.

Q: Does Firefly host the CI/CD runners to execute the Terraform runs? A: No, Firefly does not host the CI/CD runners. You are responsible for managing your CI/CD infrastructure, including runners, to execute Terraform runs.

Q: What happens to my run if Firefly's endpoint is unavailable? A: If Firefly's endpoint is unavailable, your CI/CD pipeline will operate normally. However, deployment updates won't appear in the Firefly app or dashboard until the endpoint is accessible again. Please note that pipeline execution remains unaffected, but visibility into deployment status within Firefly will be temporarily interrupted.

Q: Does Firefly have GitHub custom action? A: Yes, Firefly has a GitHub custom action that wraps the Firefly CI docker tool. View it in the GitHub Marketplace.

Q: How can I securely grant my GitHub workflow access to AWS services? A: GitHub AWS OpenID Connect (OIDC) integration allows GitHub Actions to authenticate and interact with AWS services securely. To grant the necessary permissions to your GitHub workflow for accessing your AWS account, follow the official AWS OIDC integration guide.

Q: How do I authenticate Firefly in GitHub Actions? A: Issue a new Firefly key pair. Store the access key and secret key values as repository secrets in your GitHub account: Go to your Github account > Settings > Secrets and variables > Actions > New repository secret. In the Name field, enter FIREFLY_ACCESS_KEY. In the Secret field, enter the value of the access key. Select Add secret.

Q: How do I authenticate Firefly in Azure Pipelines? A: Issue a new Firefly key pair. Store the access key and secret key values in the fireflySecrets variable group in your Pipeline Library: Go to your Azure DevOps project > Pipelines > Library > + Variable group > + Add. Under Name, enter FIREFLY_ACCESS_KEY. Under Value, enter the access key value. Select Save. After adding the pipeline, grant the Firefly pipeline access to your new variable group: Select Library > Pipeline permissions > + icon > Select the pipeline from the dropdown menu.

Q: How do I create the Azure Pipeline after merging the Firefly workflow pull-request? A: Go to your Azure DevOps project > Pipelines > New pipeline > Azure Repos Git. Select your repository > Existing Azure Pipelines YAML file > Select the default branch of your repository. Provide the path to the workflow YAML created by Firefly (/firefly-pipelines/firefly-deploy-.yaml). Verify the YAML you selected is NOT the template for the Firefly CI runner (/firefly-pipelines/templates/firefly.yaml). Select Continue > Run. You're good to go!

Q: How do I trigger the Firefly workflow on pull-requests in Azure Pipelines? A: If your code is stored in Bitbucket/Github, the pipeline is automatically triggered for PRs. If your code is stored in Azure Repos, you can add the pipeline as a Build Validation policy to make it run for PRs: Go to your Azure DevOps project > Settings > Repositories > Select your repository > Policies > Branch Policies. To add a build policy, under Build Validation, select the + icon. Select the Build pipeline you created after merging the PR from Firefly. Under Trigger, select Automatic (whenever the source branch is updated). Select Save. You're good to go!