Configuring Yandex IAM: where access breaks and why
Permissions in the cloud are almost never granted by design. Usually a role is added "just in case" so the task doesn't stall: first for yourself, then for a colleague, then for a contractor during the work.
After a couple of months, no one remembers the second and third access perimeters, and the role list contains a set that can't be explained.
Then service accounts and keys pile on top. They are created for an urgent export or integration, the key is put into build variables, a repository, and chat, and there is no rotation.
As a result, live and dead keys look the same, and it's unclear which ones are still doing something in the cloud and which should have been revoked long ago.
The peak of pain is an employee leaving. Access revocation turns into a week-long guessing game: some resources are tied to a personal account, some to a role granted for a project, and some to a service account key that no one accounted for.
While the investigation is underway, the former employee retains access to storage, and new tasks are stalled because it's unclear what can be disabled without consequences.
This isn't visible until an audit or incident happens. And then it turns out you can't answer a simple question: who had access to specific storage, who granted the permission, and what was done with that key.
That is why setting up access in the cloud starts not with the console but with an inventory: what exists, who the owner is, where users have excessive permissions, and which keys live longer than their task.
We'll break down how this is closed: audit of roles and policies, separation of service accounts by task, limited key lifetime, and a revocation procedure that takes minutes, not a week.
What managed access delivers: measurable effects
Permissions cease to be a property of a person and become a property of a role. The principle of least privilege in Yandex Cloud works by binding roles to a folder, cloud, or individual resource: a developer gets access to their own environment, not to the entire account.
An initial review of permissions usually shows that a third of accounts have more rights than needed for their work; after moving to roles, the share of excessive permissions drops to single-digit percentages.
A separate service account for each service removes shared access keys from configs, build jobs, and work machines. An access key leak stops being a total failure: the incident is limited to one service, the key is revoked with one operation, and the rest continue to work.
Access revocation time is measured in minutes — both for an employee and for a service, without searching for every place where a shared secret was stored.
Separation of duties is built on the fact that administrative roles are granted separately from work roles and not "just in case." A class of situations disappears where the same access allows you to change a setting, approve the change, and leave no trace: roles are broken down by function, and actions are logged with attribution to a specific owner.
Then access lives by policy, not memory: a scheduled review based on the log shows roles that haven't been used for months, and they are removed; when an employee leaves or changes teams, rights are revoked in minutes because they aren't tied to a shared account.
The output is a managed access perimeter: you can see who has what, what granted it, and how quickly it is closed.
Options for organizing access: roles, groups, accounts
Permissions in the cloud are granted in several ways, and each behaves differently when revoked. A direct role for a user is convenient for one-off work, but six months later no one remembers why it was granted.
Groups collect a team's identical rights in one place, inheritance to a folder distributes them to everything nested, and a service account covers automation without human involvement. Choosing a scheme is primarily choosing how cheaply you can take access back.
| Scheme | When it fits | Limitations |
|---|---|---|
| Role directly to a user | one-off grant for a specific resource, short-term work | not inherited; when a person leaves, you need to remember every grant point |
| User groups and roles | a team with the same set of tasks and stable membership | not suitable for individual exceptions — you'll have to spawn groups |
| Permissions at the resource level (folder, cloud) | a unified policy and inheritance of rights to everything nested | easy to grant more than one service needs; narrowing requires a separate folder |
| Service account | builds, integrations, background automation | a long-lived key leaks silently — rotation and audit are mandatory |
| Temporary access | audits, replacements, contractor work | it doesn't always revoke itself when the term expires; monitoring is needed |
In practice, schemes are combined: permanent staff get roles through groups with inheritance from a folder, one-off work is covered by temporary access, and automation lives on a separate service account with a minimal set of rights.
Then access revocation is one operation on a group or expiration of a term, rather than searching for direct grants across dozens of resources. This difference determines how long an investigation will take during an audit or when an employee leaves.
Access setup procedure: from audit to handover
Access in the cloud almost always grows organically: service accounts are created for a specific task, keys live for years, and roles are granted "to make it work." Changing this blindly is more dangerous than leaving it as is — first we record the current state, then design, and only then switch over.
- Account inventory. We collect service accounts, static keys, bindings to virtual machines and external systems. We separately mark records without an owner — incident investigations most often start with them.
- Access diagram. We show who accesses which resources: service to service, external integrations, people. The diagram immediately reveals extra connections and roles granted "just in case."
- Permission matrix. We reduce rights to the minimum necessary set at the folder, resource folder, and individual resource level. Each row includes the reason the access is needed.
- Setup and service migration. We grant new roles, make keys short-lived, and revoke the old ones in stages. We keep a rollback plan ready: if a service loses access, restoration takes minutes, not a night of searching for the cause.
- Testing in a test environment. We run typical scenarios — build, deployment, secret reading, storage access. The environment reveals excessive and missing permissions before they affect production.
- Handover and training. We provide documentation, the access request policy, and the key rotation procedure. After that, the customer's team manages access independently.
Handover package: configurations, diagrams, and policies
After Yandex IAM setup, the team is left not with "access that works" but with a package of artifacts that you can live by without us going forward.
Each document sits next to the access configuration, is updated by the same change, and is checked before being applied — otherwise it becomes outdated in the second week.
- Role descriptions — what each role opens, where the boundaries between similar rights are, and which one to use by default for a developer, an on-call engineer, and a build environment.
- Permission matrix — a "team / resource / role / scope / term" table: you can immediately see who has access to production and on what basis.
- Access diagrams — how service accounts, identity federation, and external contractors are connected, and through which entry point each one logs in.
- Access policy — the procedure for granting, extending, and revoking: who approves, within what timeframe, and what to do when an employee leaves or a contractor departs.
- On-call instructions — what to look at in the logs, which role to remove immediately, how to grant temporary access for an investigation, and how to return the configuration to its original state.
- Service account inventory — a list of keys with owners and rotation periods; unowned and expired ones are disabled, not forgotten.
- Production handover — a checklist walkthrough together with your engineer: access is reproduced from configuration, not kept in chat.
The package is designed for team turnover: a new engineer gets into access by following instructions, not by reading someone else's chat messages. After handover, we stay in touch to sort out disputed cases until you start managing the environment entirely on your own.
Case study: excessive permissions in a cloud environment and their revocation
Before the work, the cloud environment had been assembled organically: each team had its own service accounts, roles were granted directly to people "so as not to block the release," and static access keys sat in repositories and lived until manual revocation.
No one could say who currently had administrator rights and which of them were actually used — an audit of the cloud environment had never been performed before us.
What the access review showed
We exported all role bindings in Yandex Cloud, compared them with logs of actual requests over a comparable period, and built a picture for each subject.
It turned out that more than half of the granted permissions had never been used, and a third of service accounts had administrator-level rights where read-only access to an object would have sufficed.
A separate finding was keys without an owner: an employee had left, the account remained active, and the signature continued to work.
What we changed in the scheme
We removed direct role bindings to people — access is granted only through groups, and rights are described by policies at the folder and resource level.
For each task, we created a separate service account with the minimum sufficient role instead of a shared "do-everything" one, and replaced static keys with short-lived ones with automatic rotation.
Every key got an owner and an expiration date, and extension became a deliberate action rather than inertia.
Metrics before and after
The share of excessive permissions dropped from 48% to 7% of granted permissions, the number of active keys fell by almost three times, and not a single workflow stopped.
Access revocation time when an employee leaves or changes roles decreased from several days of manual chat to one operation on a group — minutes, with a log entry.
Incident investigation now starts not with the question "who even has access" but with a ready list: rights are described declaratively, and the current state of the environment is reproduced from configuration, not from the administrator's memory.
How do organization-level and resource-level roles differ?
An organization-level role is granted for the entire organization: access applies to all clouds, folders, and resources inside, including those that appear later.
Permissions for a specific resource are assigned at a point — folder, bucket, cluster, virtual machine — and do not work outside its boundaries.
Yandex Cloud uses hierarchical inheritance: organization → cloud → folder → resource. A role granted at a higher level is inherited downward automatically, and there are no deny rules in the model — rights only add up.
Therefore, you cannot retroactively narrow access granted at the organization level: the only option is to revoke the role entirely and re-grant it in a targeted way.
Hence a practical rule. Organization-level roles are appropriate for a narrow circle: billing administrators, security service, audit — those who, according to policy, need visibility into all folders.
We grant rights to service accounts and work groups for a specific folder or resource: then the scope of rights matches the team's area of responsibility.
The risk of broad permissions shows up in two places. Compromise of a service account key with an organization-level role opens access to the entire infrastructure, and revocation requires going through every system where a copy of the key resides.
The action is visible in the audit log, but dozens of scenarios sit behind one account — incident investigation turns into a manual search.
During an audit, we close this as follows: we collect an inventory of roles and bindings, compare the scope of rights with actual tasks, remove what is unnecessary, and reissue keys for specific folders. Access remains manageable as the number of services grows.
Common technical concerns about access and keys
Before starting, the customer's team asks the same questions: will production stop when roles change, what to do with rights accumulated over the years, and how to handle contractors who currently have shared access. Below is how we answer them in practice.
They also ask specifically about rollback: if a grant turns out to be wrong, how long does it take to return to the previous state, and is there a trace of who exactly granted the access?
Will changing permissions stop running services?
No, if you change them in the right order. First we map actual requests from the audit log, then grant new role bindings, and only after a control observation period do we revoke the old ones.
Revocation proceeds in batches with pauses — downtime is possible only where a service holds a long-lived key, and we find such places before the changes, not after.
We've accumulated extra permissions over the years — will they have to be revoked blindly?
No. We build a "service account — role — resource" map and compare it with actual calls over the observation period.
Roles with no requests are marked as candidates for revocation, but we don't touch them until the customer confirms that the service is not used seasonally. Revocation is logged: you can see what it was, what it became, and what was rolled back.
External contractors need access — how do we avoid giving away too much?
The contractor gets their own service account, limited to the necessary folder and validity period, not a key to a shared one. When the work is complete, access is revoked with a single action, without searching for traces across other people's configurations.
We rotate contractor keys on a schedule with overlap: the new one is issued and verified before the old one is revoked, so there is no downtime window.
How do we make sure permissions are set correctly?
We run test requests on behalf of each service account — both positive and negative: access to other people's folders must be denied. We manage access configurations as code, so any change is versioned and can be rolled back to the previous state. We put permission reviews on a regular cycle so accumulation doesn't start again.
Let's discuss the task and come back with an estimate and plan
For an audit of roles and service accounts in Yandex IAM to produce results, we need access to the real picture of permissions, not a retelling of it.
The first conversation takes about an hour: we discuss which teams and external contractors work with the cloud, where static keys are issued, and how the build and deployment pipeline is set up.
We also talk separately about what already hurts: deployment failures, excessive roles, and keys no one has revoked.
What to prepare for the start:
- a list of clouds, folders, and projects included in the audit;
- a list of service accounts and their purpose: build, deployment, monitoring, storage access;
- how permissions are currently granted — through the console, infrastructure-as-code manifests, scripts, or manually;
- integration points: deployment pipeline, orchestration, external contractors with access;
- segregation requirements: which environments and data must not be mixed, and where separation of duties is needed;
- the engineer responsible for access who confirms decisions during the work.
We request minimal access for the audit — read-only access to policies and account metadata. We do not touch roles and keys themselves during the review stage: changes happen in a separate stage, after the scheme is approved.
Based on the results, we come back with an access work plan: stages, the order of service account migration, rollback points, timeline estimates, and the target role model. If some data is unavailable, we record that in the plan and suggest what to replace it with.
Describe the task — we'll come back with an estimate and plan.