RBAC Use Cases and Best Practices

RBAC gives Fugue a mechanism to control principals (users), actions (operations) the principals can peform, and which subjects (targets) the actions be performed on. We’ve covered this concept from a high-level standpoint, provided insight into how it works, and created a great hands-on walkthrough. We thought it may also be helpful to demonstrate some additional scenarios.

Note: This example use case includes a policy (composition) with types taken directly from the Fugue.System.Policy library to form rules, which are the keystone of the Fugue RBAC system.

Use Case(s)

The users and rules included in the example are:

Alice - Administrator: Alice is an administrator with the ability to perform any operation on any resource that Fugue knows about. While Alice is an administrator, her access differs specifically from root because she does not have the ability to perform actions related to users or accounts.

Bob - Web Developer: Bob is a web developer and he has the ability to perform run, update, and kill for any compositions in the web account, but does not have permission to manage compositions in other accounts. One thing to note, in our example we’ve only explicitly included the single account for web, however there’s a direct comparison to either Alice or Charlie, who can perform actions on all accounts.

Charlie - Analyst: Charlie is an analyst and has the ability to add or move accounts within Fugue but cannot perform any actions on compositions. Note that function applied to Charlie varies from Bob because it specifically references account tables.

David - Intern: David is an intern with limited access to Fugue. He has the ability to check the status of the process aliased “Network,” but he is restricted from all other actions in all other accounts and processes.


import Fugue.System.Policy as Policy

alice: Policy.User {userId: "alice"}
bob: Policy.User {userId: "bob"}
charlie: Policy.User {userId: "charlie"}
david: Policy.User {userId: "david"}

web: Policy.Account {accountId: "web-1483061704854"}
Policy.Process network: Policy.AliasedProcess {alias: "Network"}

aliceAdmin: Policy.accountRules {
  principals: [alice],
  accounts: [Policy.AllAccounts],
  actions: Policy.allAccountActions

bobCanRunInWeb: Policy.accountRules {
  principals: [bob],
  accounts: [web],
  actions: [

charlieAcctTable: Policy.accountTableRules {
  principals: [charlie],
  actions: Policy.allAccountTableActions

davidStatusNetwork: Policy.Rule {
  principal: david,
  subject: Policy.ProcessType(network),
  action: Policy.ProcessAction(Policy.ProcessGetStatus)

Best Practices, Things to Avoid, and Caveats

  • Avoid using root for day to day operations. This user should be reserved for key administrative tasks and creation of initial policy.
  • When creating policy provide the minimum permissions required to perform the desired actions. In other words, providing administrative-level access to a wider group of users is an invitation for trouble and should be avoided.
  • Users defined in an RBAC policy should only have certain IAM permissions in the account the Fugue Conductor runs in, as some permissions will enable users to potentially subvert the RBAC system. Refer here for the complete IAM policy. We recommend running the Fugue Conductor in its own “control plane” account that is locked down to all but Fugue root-level administrators.
  • Compiled policy must be <10MB.


Do not lose your root credentials. They cannot be replaced with the policy generate-secret command. If you have lost your root credentials, contact support@fugue.co.