---
title: "IAM recipes"
description: "Policies for staging-only editors, access by flag key prefix, and denying production changes."
---

> Documentation Index
> Fetch the complete documentation index at: https://docs.ezghcloud.com/llms.txt
> Use this file to discover all available pages before exploring further.

# IAM recipes

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:

```json
{
  "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:

```json
{
  "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:

```json
{
  "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](/iam/api-keys)
for a [bot](/iam/bots) with a policy like the ones above.

Source: https://docs.ezghcloud.com/flags/iam/index.mdx