Access policies
Note
This feature is in the Preview stage. To get access, contact tech support
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 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:
- 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.
- 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.adminoradminfor the folder or cloud to manage access policies at the folder or cloud level, respectively.organization-manager.adminoradminfor the organization to manage access policies at the organization level.
Resources 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 templates
Some access policy templates require you to specify additional parameters when assigned to a resource; others do not.
Templates 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.denyServiceAccountCreation
This policy prohibits creating service accounts.
iam.denyServiceAccountAccessKeysCreation
This policy prohibits creating static access keys for service accounts.
iam.denyServiceAccountApiKeysCreation
This policy prohibits creating API keys for service accounts.
iam.denyServiceAccountAuthorizedKeysCreation
This policy prohibits creating authorized keys for service accounts.
iam.denyServiceAccountFederatedCredentialsCreation
This policy prohibits associating service accounts with workload identity federations.
iam.denyServiceAccountCredentialsCreation
This policy prohibits the following:
- Creating any credentials for service accounts (except IAM tokens).
- Associating service accounts with workload identity federations.
iam.denyServiceAccountImpersonation
This policy prohibits impersonation.
organization.denyMemberInvitation
This policy prohibits inviting new Yandex account users to the organization. The policy can be created only for an organization.
organization.denyUserListing
This policy prohibits viewing the list of organization users. The policy can be created only for an organization.
Templates with additional parameters
The following access policy templates allow their restrictions to be modified by additional parameters:
serverless.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_idshas priority over other parameters: if a non-empty value is set for it, the values ofsrc_ip_restricted_network_idsandallowed_src_ipswill 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 theallowed_src_ipsparameter. -
allowed_src_ips: List of private IP addresses or CIDR IP address ranges that belong to the networks specified in thesrc_ip_restricted_network_idsparameter, and from which function and container calls are allowed.
See also the examples of assigning a policy template.
serverless.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.