Skip to content

IAM recipes

Policies for staging-only editors, access by flag key prefix, and denying production changes.

Updated View as Markdown

Changing a flag’s targeting (flags.configs.update) and reading it (flags.configs.get) are checked against the environment, with the flag’s key as the path:

ezgh:us-west-1:org_k3f9a0x2m7qp:prj_g7h8i9j0k1l2:fen_8k2m9x0q4r1s/new-checkout

So a policy can allow targeting changes in one environment, or only for some flags:

Resource pattern Matches
…:fen_<staging>/* Every flag’s targeting in staging
…:fen_*/checkout-* The targeting of flags whose keys start with checkout-, in every environment
…:prj_<project>:* Everything in the project

The environment’s own resource name, without a path, doesn’t match targeting actions. Use fen_<id>/* (or broader) to allow them, and fen_<id>* or fen_<id>/* in a deny meant for an environment’s targeting. Flag keys have no /, *, : or ., so a pattern can’t reach outside its environment.

An environment’s resource name is on its page in the console, and in ezgh flags envs get <key>.

Editors in staging only

Attach FlagsReadOnlyAccess, so they see everything in the project, and a policy that lets them change targeting in staging only:

{
  "statements": [
    {
      "effect": "allow",
      "actions": ["flags.configs.update"],
      "resources": ["ezgh:us-west-1:org_k3f9a0x2m7qp:prj_g7h8i9j0k1l2:fen_4s7d2k9q1x0m/*"]
    }
  ]
}

In the console, they see production’s targeting read-only, with the permission they’re missing.

Checkout flags only

A team that owns the flags whose keys start with checkout-, in every environment:

{
  "statements": [
    {
      "effect": "allow",
      "actions": ["flags.configs.get", "flags.configs.update"],
      "resources": ["ezgh:us-west-1:org_k3f9a0x2m7qp:prj_g7h8i9j0k1l2:fen_*/checkout-*"]
    }
  ]
}

Everything but production

Attach FlagsFullAccess, and deny changes to production’s targeting, its new SDK keys and the environment itself:

{
  "statements": [
    {
      "effect": "deny",
      "actions": ["flags.configs.update", "flags.sdkKeys.create", "flags.environments.update", "flags.environments.delete"],
      "resources": ["ezgh:us-west-1:org_k3f9a0x2m7qp:prj_g7h8i9j0k1l2:fen_8k2m9x0q4r1s*"]
    }
  ]
}

fen_8k2m9x0q4r1s* matches the environment and every flag’s targeting in it. Revoking a key is checked against the key (fsk_…), not its environment.

Workloads

Server SDK keys aren’t API keys: they read one environment’s flags and do nothing else, and they belong to the environment. A deploy pipeline that changes targeting uses an API key for a bot with a policy like the ones above.

Navigation

Type to search…

↑↓ navigate↵ selectEsc close