As a platform engineer tasked with integrating Runway for FinOps reporting, I've encountered a significant and predictable hurdle: the default permission model is far too permissive for handling sensitive financial data. Our organization requires strict adherence to the principle of least privilege, especially for cloud cost data which contains details about every service and resource across our multi-cloud footprint. The current roles and resource-based permissions feel like a maze, where a single misconfiguration could expose sensitive cost allocations or allow unintended modifications to critical business logic.
My primary objective is to construct a permission schema that achieves the following key outcomes:
* **Segregation of Duties:** Engineering teams should view cost dashboards and reports for their specific applications or cost centers, but must have zero ability to modify data sources, custom fields, or reporting rules.
* **Financial Data Governance:** The FinOps team requires full administrative access to configure integrations, define business mappings, and set budgets. However, they should not have the ability to manage user invitations or alter core platform settings unrelated to cost.
* **Read-Only Executive Reporting:** A subset of stakeholders should have access to a curated set of high-level dashboards with no ability to drill down into raw, unaggregated resource-level data or export beyond predefined formats.
The provided documentation on custom roles and resource permissions is a starting point, but lacks concrete examples for complex, real-world scenarios. I am particularly interested in the interplay between these three permission layers:
1. **Global Roles:** (e.g., Admin, Member, Viewer)
2. **Resource-Specific Permissions:** Applied to individual dashboards, reports, or data sources.
3. **API Token Scopes:** For any automated access we might implement.
Has anyone successfully architected a granular permission structure for a similar use case? I am looking for specific examples, preferably in Terraform or via the Runway API, that demonstrate how to lock down financial data effectively. For instance, how would you codify a role that allows a user to view only dashboards tagged with their specific `cost-center:platform-engineering`?
```hcl
# Hypothetical Terraform structure for a custom role - is this granularity possible?
resource "runway_custom_role" "cost_center_viewer" {
name = "cost-center-viewer"
description = "Can view dashboards tagged with their specific cost center."
permissions = [
"view:dashboard", # But only if resource tag matches user attribute?
"export:report:pdf", # Only for permitted dashboards?
# Explicit denies for:
# - "modify:datasource"
# - "view:rawdata"
# - "modify:customfield"
]
}
```
Furthermore, what are the observed pitfalls? Does the permission model properly cascade, or are there edge cases where inherited permissions from a global "Viewer" role might override more restrictive resource-level settings? Any insights into auditing access logs to verify the effectiveness of the permission scheme would also be highly valuable.
infra nerd, cost hawk
Yeah, that principle of least privilege goal is spot on and really non-negotiable for financial data. It sounds like you've already hit the core tension in these platforms, where the default settings are built for ease of adoption, not strict governance.
I'm curious, when you say the roles and resource-based permissions feel like a maze, is that because the available roles are too broad, or because the resource-level controls are too granular and hard to manage at scale? I've seen teams get stuck both ways.
Your split between engineering teams (view-only for their slice) and the FinOps team (full admin on the data side, but not on user management) is a solid starting framework. Have you looked into whether Runway supports custom roles, or if you'd need to achieve this through a combination of their built-in roles and careful resource tagging? Sometimes the answer is a mix.
— Jane
That predictable hurdle is the whole point. These platforms aren't designed for your level of governance out of the box. The maze isn't a bug, it's a feature to sell you on their "enterprise" tier where they finally let you build custom roles.
You're building a schema on a foundation of sand. Runway's permission model will change in six months when they "simplify the user experience," and your carefully crafted segregation of duties will be broken by a default checkbox in a UI update.
Stick to exporting the raw data to a warehouse you control and building access there. At least you can version control IAM policies.
If it ain't broke, don't 'upgrade' it.