Yandex Cloud
Search
Contact UsTry it for free
  • Customer Stories
  • Documentation
  • Blog
  • All Services
  • System Status
  • Marketplace
    • Featured
    • Infrastructure & Network
    • Data Platform
    • AI for business
    • Security
    • DevOps tools
    • Serverless
    • Monitoring & Resources
  • All Solutions
    • By industry
    • By use case
    • Economics and Pricing
    • Security
    • Technical Support
    • Start testing with double trial credits
    • Cloud credits to scale your IT product
    • Gateway to Russia
    • Cloud for Startups
    • Center for Technologies and Society
    • Yandex Cloud Partner program
    • Price calculator
    • Pricing plans
  • Customer Stories
  • Documentation
  • Blog
© 2026 Direct Cursus Technology L.L.C.
Yandex Identity and Access Management
    • Overview
      • Overview
      • Roles
      • Access policies
      • System groups
      • Public groups
      • Resources that roles can be assigned for
      • Impersonation
    • Service access to user resources
    • Identity federations
    • Workload identity federations
    • Quotas and limits
  • Secure use of Yandex Cloud
  • Access management
  • Pricing policy
  • Role reference
  • Terraform reference
  • Monitoring metrics
  • Audit Trails events
  • Release notes

In this article:

  • Relationships between access policies and roles
  • Resources that take access policies
  • Access policy templates
  • Templates without additional parameters
  • Templates with additional parameters
  1. Concepts
  2. How access management works
  3. Access policies

Access policies

Written by
Yandex Cloud
Updated at April 3, 2026
  • Relationships between access policies and roles
  • Resources that take access policies
  • Access policy templates
    • Templates without additional parameters
    • Templates with additional parameters

Note

This feature is in the Preview stage. To get access, contact tech support or your account manager.

Access policies are a Yandex Identity and Access Management mechanism that allows you to manage permissions for performing specific operations on Yandex Cloud resources. Access policies complement the role system for more flexible access management.

Access policies for resources are created based on access policy templates.

Relationships between access policies and rolesRelationships between access policies and roles

Access policies enforce explicit restrictions, unlike roles, which grant explicit permissions. The relationships between access policies and roles are as follows:

  • To perform an operation, it must be allowed by a role and not prohibited by an access policy. Access permissions are checked in the following order:

    1. The system checks if the user is assigned a role required to perform the operation. If they have no such role, the operation is denied without any further checks.
    2. If the user has the required role, the system checks access policies for an explicit restriction to perform the operation and denies or allows the operation accordingly.
  • Access policies do not replace roles, but add an extra layer of access control. Users still need relevant roles for operations, regardless of the access policies in place.

  • To manage access policies, a user must have one of the following roles:

    • resource-manager.admin or admin for the folder or cloud to manage access policies at the folder or cloud level, respectively.
    • organization-manager.admin or admin for the organization to manage access policies at the organization level.

Resources that take access policiesResources that take access policies

You can create access policies for the following resources:

  • Organization: Access policy applies to resources in all clouds and folders within an organization.
  • Cloud: Access policy applies to resources in all folders within a cloud.
  • Folder: Access policy applies only to resources within a specific folder.

Access policies created at higher levels of the Yandex Cloud resource hierarchy are inherited by lower-level resources.

You can create several access policies for one resource at the same time.

Access policy templatesAccess policy templates

Some access policy templates require you to specify additional parameters when assigned to a resource; others do not.

Templates without additional parametersTemplates without additional parameters

The following access policy templates do not contain additional parameters and unconditionally restrict relevant actions:

  • iam.denyServiceAccountCreation
  • iam.denyServiceAccountAccessKeysCreation
  • iam.denyServiceAccountApiKeysCreation
  • iam.denyServiceAccountAuthorizedKeysCreation
  • iam.denyServiceAccountFederatedCredentialsCreation
  • iam.denyServiceAccountCredentialsCreation
  • iam.denyServiceAccountImpersonation
  • organization.denyMemberInvitation
  • organization.denyUserListing

iam.denyServiceAccountCreationiam.denyServiceAccountCreation

This policy prohibits creating service accounts.

iam.denyServiceAccountAccessKeysCreationiam.denyServiceAccountAccessKeysCreation

This policy prohibits creating static access keys for service accounts.

iam.denyServiceAccountApiKeysCreationiam.denyServiceAccountApiKeysCreation

This policy prohibits creating API keys for service accounts.

iam.denyServiceAccountAuthorizedKeysCreationiam.denyServiceAccountAuthorizedKeysCreation

This policy prohibits creating authorized keys for service accounts.

iam.denyServiceAccountFederatedCredentialsCreationiam.denyServiceAccountFederatedCredentialsCreation

This policy prohibits associating service accounts with workload identity federations.

iam.denyServiceAccountCredentialsCreationiam.denyServiceAccountCredentialsCreation

This policy prohibits the following:

  • Creating any credentials for service accounts (except IAM tokens).
  • Associating service accounts with workload identity federations.

iam.denyServiceAccountImpersonationiam.denyServiceAccountImpersonation

This policy prohibits impersonation.

organization.denyMemberInvitationorganization.denyMemberInvitation

This policy prohibits inviting new Yandex account users to the organization. The policy can be created only for an organization.

organization.denyUserListingorganization.denyUserListing

This policy prohibits viewing the list of organization users. The policy can be created only for an organization.

Templates with additional parametersTemplates with additional parameters

The following access policy templates allow their restrictions to be modified by additional parameters:

  • serverless.restrictPrivateNetworkInvocation
  • serverless.restrictPublicInvocation

serverless.restrictPrivateNetworkInvocationserverless.restrictPrivateNetworkInvocation

Note

The serverless.restrictPrivateNetworkInvocation policy requires an active service connection from Yandex Cloud Functions and Yandex Serverless Containers to Yandex Virtual Private Cloud.

This policy limits calling functions and containers from Yandex Virtual Private Cloud's private IP addresses to explicitly specified cloud networks or specific IP addresses within them.

There must be a cloud network from the list specified in the policy parameters linked to the function/container.

Additional parameters:

  • allowed_vpc_network_ids: List of cloud networks in which function/container calls are allowed from any private IP addresses.

    allowed_vpc_network_ids has priority over other parameters: if a non-empty value is set for it, the values of src_ip_restricted_network_ids and allowed_src_ips will be ignored by the policy.

  • src_ip_restricted_network_ids: List of cloud networks in which function/container calls are allowed only from the private IP addresses specified in the allowed_src_ips parameter.

  • allowed_src_ips: List of private IP addresses or CIDR IP address ranges that belong to the networks specified in the src_ip_restricted_network_ids parameter, and from which function and container calls are allowed.

See also the examples of assigning a policy template.

serverless.restrictPublicInvocationserverless.restrictPublicInvocation

The serverless.restrictPublicInvocation policy restricts the ability to call functions and containers from public IP addresses.

Additional parameters:

  • allowed_src_ip: List of public IP addresses or CIDR IP address ranges from which function and container calls are allowed.

See also the example of assigning a policy template.

See alsoSee also

  • Roles
  • Getting a list of supported access policy templates
  • Creating an access policy for a resource
  • Viewing access policies created for a resource
  • Deleting an access policy

Was the article helpful?

Previous
Roles
Next
System groups
© 2026 Direct Cursus Technology L.L.C.