Let me guess how your last data pipeline got its permissions. Something failed at 4 p.m., a role was missing an action, and somebody attached a much bigger policy so the job would run before the dashboards refreshed. We have all done it. This post looks at six myths behind that habit, using the vocabulary of IAMOps, an informal label for treating access rules as code you design, test and improve over time.<\/p>\n
A quick note on sources: the facts here come from the Ops Atlas page about IAMOps<\/a>, which also admits that the term is a working label, not an official discipline. Take what is useful, ignore the branding.<\/p>\n It sounds sensible because the deadline is real. The trouble is what “later” looks like. Once the pipeline has run for a month with broad rights, the usage data shows many actions in use, and that evidence seems to prove the access is needed. Nobody dares to cut it. A better pattern is to start with the handful of actions you know the job performs, watch the denials, and add only what the logs justify. Narrow-then-widen feels slower on day one and saves weeks afterwards.<\/p>\n Ready-made policies are a fine starting point, and the Atlas notes that their authors warn they may not be least-privilege. They are written to cover many customers, so they tend to be wide. Treat a managed policy as scaffolding. Once your job has run for a few weeks, compare what it allows with what the job did and write a tighter custom version.<\/p>\n If your transformation layer is built with a tool like the one in this walkthrough of building models with dbt for modern pipelines<\/a>, you already have a precise list of tables the job reads and writes. That list is the raw material for a custom policy.<\/p>\n This one catches clever people. Organisation-wide guardrails, such as service control policies in AWS, never give anyone access. They only draw the outer boundary. A guardrail that says “these actions are permitted” does not create a single permission; some identity or resource policy still has to grant it. And where an explicit deny exists, it wins. When a job fails despite an “allow” at the top, check for the missing grant lower down before blaming the platform.<\/p>\n Federation is a big step forward because it replaces long-lived keys with short-lived tokens. But a loose condition can undo the benefit. The Atlas gives a pointed example: a subject pattern that admits every repository in an organisation lets any repo’s workflow assume the role. Use exact per-environment subjects, for instance one for the production branch of one repository, so the pipeline’s trust matches its real scope.<\/p>\n Here is a subtle one. If a rule says “allow unless the tag equals X”, it behaves differently when the tag is missing entirely. According to the Atlas, negated operators such as not-equals can match when the key is absent, whereas positive operators simply fail. In data platforms, where tags and labels are inconsistently applied, that difference matters. Prefer positive conditions on attributes you control, and test the missing-key case on purpose. A test that feeds the policy a request with no tag takes five minutes.<\/p>\nMyth 1: “Grant admin now, tighten it later”<\/h2>\n
Myth 2: “A vendor-managed policy is least privilege”<\/h2>\n
Myth 3: “Our organisation-level rule allows it, so we’re fine”<\/h2>\n
Myth 4: “Conditions on the token make the role safe”<\/h2>\n
Myth 5: “A negative condition is just a safer positive one”<\/h2>\n