Best practices for assigning access in an enterprise

While you're deciding how to set up your account structure within the enterprise, begin planning how to assign access to identities in your organization. These best practices provide you with the basic building blocks to enable successful and secure app development in IBM Cloud®.

To learn more about organizing resources and assigning access in child accounts or nonenteprise accounts, see Best practices for organizing resources and assigning access.

How enterprise-managed IAM access works

Centrally manage identity and access management (IAM) for your organization by using IAM templates to assign access and manage security settings. Create templates for IAM resources in your enterprise accountA unique account within an enterprise that manages users and access for account organization and enterprise billing. to standardize access groups, trusted profiles, and security settings across accounts in your organization. After you assign an IAM template, the child accounts that you select are assigned an enterprise-managed IAM resource with the associated attributes, like settings, policies and action controls. Action controls determine whether administrators of IAM services in child accounts can modify the enterprise-managed resource in their account.

Users in a child account can determine that an IAM resource comes from an enterprise-managed IAM template by the enterprise-managed tag on the resource in the console. The API response for enterprise-managed IAM resources in child accounts includes a “template” section.

Depending on how you configure the action controls for an IAM template, child accounts might modify the IAM resource that you assigned. In this case, only that instance of the resource is impacted. An instance of the same IAM resource in a different account isn't affected.

One advantage of IAM templates is the reduced time and effort to manage access in your organization. For example, instead of creating an access group with the same permissions in each account, create one access group template at the enterprise level, and assign that access group template to child accounts. The assignment creates the access group and its associated policies in each child account, saving you from manually creating hundreds of policies. Learn about other strategies for Reducing time and effort to manage access.

IAM templates help prevent policy drift by using the practice of immutable infrastructure. Immutable infrastructure is a DevOps practice that helps ensure all enterprise-managed IAM resources remain in a consistent state, reducing the risk of configuration errors. With immutable infrastructure, any changes to a template are made by creating a new instance or version of the template, rather than modifying an existing one. This means that the history of the template can be easily traced, as each instance or version represents a specific point in time. Tracking changes through the creation of new instances provides an audit trail that can help identify and address any security issues, making your IAM resources more reliable and secure. For more information about auditing enterprise IAM events, see Monitoring enterprise IAM templates.

With enterprise-managed IAM, you can grow your organization at scale. By assigning instances of templates as needed, you can avoid the complexity and risk of modifying existing instances. This way, it's easier to assign existing templates to new accounts.

Test a new template version in select accounts before you assign it to wider audiences. You can roll back to a past version if the new version doesn't behave the way that you want.

When should I use an IAM template?

To know when to use a template to assign access or manage child account settings in your enterprise, consider the following factors:

Number of child accounts: If you have many child accounts, it can be time-consuming and error-prone to manually configure access policies and settings for each account. In this case, by using IAM templates, you can save time and ensure consistency across all accounts.
Common access requirements: If all or most of the child accounts require the same access policies, it makes sense to use a template to apply these policies uniformly. This ensures that all accounts have the necessary permissions to perform their intended tasks.
Security requirements: If you have strict security requirements, such as compliance with industry regulations or company policies, IAM templates can ensure that all child accounts are configured to meet those requirements and stay compliant. This can help reduce the risk of security breaches and unauthorized access.
Changes to access policies: If you need to update access policies for multiple child accounts, IAM templates can make the process more efficient. Instead of manually updating each account, you can update the template and apply the changes to all accounts at once.
Secure by default: If you need to ensure that new accounts are configured to your standards by default, you can assign an IAM template to an account group. Assigning a template at the account group level ensures that new accounts that you create within that account group, or existing account that you move to it, are automatically assigned the same template.

Access group templates

An access group template is a predefined access group with a set of associated access policies that can be applied to one or multiple child accounts or account groupsAn organizational unit for accounts within an enterprise. An account group can contain accounts or other account groups.. Access group templates can include permissions for different services and resources, and the level of access for the group. By using access group templates, enterprise administrators can ensure that child accounts with common access requirements are configured with the same access policies, reducing the risk of misconfigurations and unauthorized access.

For more information, see Creating enterprise-managed access group templates.

Trusted profile templates

With trusted profile templates, you can automatically grant federated users access to child accounts with conditions based on SAML attributes from your corporate directory. You can skip the account invitation process and define conditions that map the people in your organization to the right account. This way, the right access is already set up for them when they apply a trusted profile.

For more information, see Creating enterprise-managed trusted profile templates.

Settings templates

Enterprise-managed settings templates ensure that IAM settings, like restricting domains for account invitations and setting limits for login sessions, are consistent across multiple accounts. You can assign a settings template to existing accounts and to accout groups to help streamline the process of creating new accounts that are secure by default. By selecting an account group, you assign a settings template to existing and future child accounts of that group. Administrators can apply the appropriate template to an account group to ensure that new accounts are configured consistently and in compliance with organizational policies and best practices. This can save time and reduce the risk of misconfiguration or security vulnerabilities.

For more information, see Creating enterprise-managed settings templates.

Access policy templates

Access policy templates define a policy without requiring a subject, and you can use them to grant access to multiple subjects.

Spend less time on configuring individual policies and use access policy templates to quickly grant the right access in access group and trusted profile templates. For more information, see Creating access policy templates.

Action controls

Action controls are a mechanism to define the operations that administrators of IAM services in child accounts can take on the enterprise-managed IAM resources that you assign to their account. For example, by default an action control prevents access group administrators from adding access policies to an enterprise-managed access group.

Action controls are available only for access group templates.

For access group templates, the best practice is to restrict changes to policies, but to allow access group administrators to add members. This way, you can create role-based access group templates with the right access for those roles and delegate managing membership to the access group administrators in child accounts. Learn more about the available action controls for access group members, dynamic rules, and access policies.

How can I grant access to child account resources with IAM templates?

Resources that users provision in your enterprise reside in child accounts. The best way to organize resources in child accounts is by using access management tags. When you assign IAM templates across multiple accounts, the access policies must contain a resource pattern that's applicable to all child accounts that you target. For example, you can't specify a resource group in an enterprise-managed IAM policy because the GUID that identifies a resource group is unique. However, you can specify a pattern that matches common access management tags in your organization.

Some services, like account management services, don't have provisionable resources, so you don't need to scope policies for those services to specific resources.

Use IAM templates to grant access in child accounts to resources like all of a service's resources, all resources with a specific tag, or all resources in the account. Review the following sample access policies to help you determine how you might want to grant access in access group and trusted profile templates.

Sample access policy for account management services

Account management roles are a great candidate for enterprise-managed access group and trusted profile templates because there aren't specific resources to scope the policy to.

A policy that grants a platform administrator role on the group of All IAM Account Management services. This policy is appropriate for IAM administrators in your organization.

Sample access policy for all resources in the account

A policy that grants a platform administrator role on the entire account, All IAM-enabled services. The users with this access can perform any platform actions on any resource in the entire account and management actions, such as managing resource groups and attaching and detaching tags in the account.

Sample access policy for a resource group only

A policy with a viewer role on Resource group only. Users with this policy have visibility to view all resource groups in an account. This policy is required to create instances of any service in a resource group in addition to a role on the service that they want to create an instance of.

Sample access policy for all of a service's resources

A policy that grants a platform administrator role on the IBM Cloud Kubernetes Service. Users with this policy can access all instances of the service. Users with an administrator role that is assigned on any resource can also grant access to that resource.

Sample access policy for a specific group of resources

You can create policies with more granularity by using access management tags.

A policy with an administrator role on all IAM-enabled services. Scope the policy to specific resources by selecting the attribute for access management tags. Enter the project:chatbot tag, which gives users administrator access in child accounts to all of the resources with that tag. This way, they have the access that they need for that specific project.

Compare access groups and trusted profiles

Access groups are best used for granting access for a user's day-to-day work, while trusted profiles are suited for granting federated users the level of access they need to complete a specialized and specific set of tasks within a limited time period. These are usually critical tasks that you would want to avoid doing unintentionally in daily work. With trusted profiles, federated users don't need to onboard to IBM Cloud, they are granted access to IBM Cloud resources in an account by way of the trust relationship. If a federated user leaves your company, you can simply delete their corporate identity in your directory, which then also removes access to IBM Cloud. Time-based access with trusted profiles allows frequent authentication checks for reduced security risks.

Use the following table to understand the differences between using access groups and trusted profiles to make the best decision for your use case.

Table 1. Compare access groups and trusted profiles
Feature	Access group	Trusted profile
IAM access control	Yes	Yes
Inviting users to the IBM Cloud account required	Yes	No
Access can be defined before user is added to the account	Yes, by using dynamic rules	Yes
Federated users	Yes	Yes
Non-federated users	Yes	No
Service ID	Yes	No
Compute resource identities	No	Yes
User management is primarily done in	IBM Cloud account	Corporate user directory

Access groups and trusted profiles can be used separately or hand-in-hand for user and access management, depending on your organization's needs.

For example, for the CustApp project, you might choose to create an IAM Admin trusted profile with the following policies:

Administrator for access groups CustApp-Dev/Test/Prod. This way, the administrator can grant and revoke access to users by adding them to and removing them from access groups.
Administrator for IAM Identity account management service. This way, the administrator can manage service IDs, trusted profiles, rules, and so on.
Editor for User Management account management service. This way, the administrator can invite users to the account, view users in account, and so on.

With this trusted profile, the administrator can add developers to an access group with broad access policies to complete day-to-day actions and tasks in the development and test environments. Access for operations on the production environment can be set up in a trusted profile named Operator-Profile. This way, the developer can change job roles by logging in and applying the Operator-Profile when they need to take any operation actions on the CustApp in production.

If you have administrator access through a trusted profile, it is not recommended to invite users to an account while the profile is applied. Users should be invited by true account owners or administrators, or an error might occur.

Reducing time and effort to manage access

There is a limit on the total number of policies that are allowed in an account. You can use a few strategies to ensure that you don't reach the limit and to reduce the amount of time that you spend managing access for the identities in your account (users, service IDs, or trusted profiles):

Use the principle of least privilege and assign only the access that is necessary. This can help you ensure that the identities in your account are limited to only the actions that you want to allow. For example, time-based conditions for access policies grant access during only the timeframe you specify, reducing the opportunity for attack in the event of a security breach. For more information, see Limiting access with time-based conditions.
Add resources to a resource group to further minimize the number of necessary policies. For example, you might have a team working on a project that uses specific resources in your account. Add the team members to an access group or trusted profile with a policy that assigns access to only the resources that are in a specific resource group. This way, you don't need to assign a policy to each resource for each team member.
Use access groups to streamline managing access for identities that require the same level of access. You can set up an access group with a specific policy defined, and then add those identities to the group. If the group members need more access later on, you simply define a new policy for the access group.
Use access management tags to control access to the resources and service IDs in your account at scale. By assigning access only to resources and service IDs that have specific tags that are attached to them, you can avoid multiple updates to your defined policies. For more information, see Controlling access to resources by using tags.
Use trusted profiles to automatically grant federated users and compute resources access to your account. This way, federated users can be mapped to one or more trusted profiles during login by evaluating SAML-based attributes to determine which profiles they can apply. Using trusted profiles for compute resources helps you avoid storing credentials to run applications and the management and rotation of credentials. You can also add trusted profiles to access groups to leverage the set of policies you have already created.
Assign access by using a group of services so that you need only a single policy to assign access to multiple services. This way, you decrease the number of policies in your account and reduce the time and effort to manage access.
- All Identity and Access enabled services: All catalog services that use IAM for access management.
- All Account Management services: Platform services, such as billing and usage, license and entitlements, enterprises, and more. For more information, see Assigning access to account management services.
- All IAM Account Management services: A subset of account management services that includes the IAM platform services IAM Identity, IAM Access Management, IAM Users, IAM Groups, and future IAM services.

Removing access for inactive identities and inactive policies can reduce the risk of unauthorized access to your IBM Cloud resources and help you manage access more efficiently. For more information, see Identifying inactive identities and Auditing access policies.

For more information about IAM access and the available features, see How IBM Cloud IAM works.

Use cases for assigning enterprise-managed IAM templates

Review the following use cases to develop a customized plan that suits the needs of your enterprise. For each use case, it's recommended to use enterprise-managed IAM templates to maintain consistency and compliance by centrally managing IAM for an organization.

Multiple accounts require common access policies

Developers and administrators in my enterprise's child accounts have different access needs. Administrators need to configure Container Registry and create and manage Kubernetes clusters. Developers need to build and deploy apps by using Kubernetes. You can assign users service access roles to namespaces within clusters in accounts across your organization so that users have the minimum privileges they need to do their job. Make sure that your organization is using a consistent naming pattern for namespaces so that your policies work as you intend.

I create an access group template for each job role:

Create an access group template for developers. Assign a policy with Writer service access role for the Kubernetes namespace test in all clusters.
Create an access group template for administrators and assign two policies. First, assign a policy with the Manager role on the Kubernetes service. Next, assign a policy with the administrator role on the Container Registry service.

For each access group template, set the action control for adding members to Yes so that access group administrators in child accounts can add the right members to the enterprise-managed access group in each account.

When you assign access to a namespace, the policy applies to all current and future instances of the namespace in any cluster in the account that you authorize.

A few users need temporary access to all accounts

I need to give compliance focals that are responding to audit evidence requests access to all of my existing accounts so that they can view billing resources and generate reports.

Create a trusted profile template that has Viewer access on the Billing service in the accounts where I assign the template. Include a time-based condition that grants access for the minimum amount of time that the compliance focals need access.
Create conditions based on attributes from my identity provider (IdP). The attributes target the compliance focals, who are normally not members of any particular account.

If a user meets the conditions, they can apply the trusted profile in each account where the template is assigned.

The compliance focals can collect the evidence that the team of auditors need to accomplish their yearly audit by applying the trusted profiles. The focals can finish gathering evidence until the time-based condition expires. If they need more time, create a new version with the alotted time and update the template assignment.

Enforce MFA for new and existing accounts

My company has a new compliance regulation that requires all new and existing accounts to use multifactor authentication (MFA).

Create a settings template that defines the level of MFA that my company requires. Assign the settings template to all account groups.

All existing accounts now require users to log in with MFA. Any time that a new account is created within an account group, it inherits the settings template. This way, all new accounts automatically comply with the company compliance regulations.

Assigning access in multiple environments by using tags

Some users in my enterprise's child accounts need access to resources in different environments within account groups. Account groups in my enterprise have two child accounts. Development and test environments reside in one account, and production environments are in a separate account. Resource administrators in my enterprise use access management tags to group env:dev, env:test, and env:prod resources in their accounts. They also group resources by using the tags resource:storage, resource:containers, resource:security. This way, enterprise administrators can create more granular policies for different environments in the enterprise.

I create an access group template for each type of user that exists in child accounts that contain development and test environments:

Create an access group template for users who need to debug code. Assign a policy with a reader role on all IAM-enabled services. Scope the policy to specific resources by selecting the attribute for access management tags. Enter the tags env:dev and resource:storage, which gives child account users in the enterprise-managed access group reader access to storage resources in the development environment.
Create an access group template for users who need to push code to development and test environments. Assign a policy with a writer role on all IAM-enabled services. Scope the policy to specific resources by selecting the attribute for access management tags. Enter the tags env:dev, env:test, resource:storage, and resource:containers, which gives child account users in the enterprise-managed access group administrator access to storage and containers resources in development and test environments.