External Identity Interactions
IBM Cloud is introducing a new security setting called External Identity Interactions. IBM Cloud users can belong to multiple accounts. Many cloud services allow an authenticated user who has permissions in your account to make API calls even if the user is currently logged in with a different account context. Because users can authenticate with an API key, this might allow a user who has permissions in your account to authenticate with an API key that was created in a different account and perform actions in your account. Since you don’t control the ability of users to create user API keys in their other accounts, or control other aspects of API key usage such as how frequently they are rotated, this setting is being introduced to enable you to block any API calls from authenticated users if those users are currently in the context of a different account.
The External Identity Interactions setting does not prevent you from adding specific users, service IDs, or compute resources in other accounts to a trusted profile. Using trusted profiles lets you allow specific identities in other accounts to assume an identity in your account and perform actions. Since those identities are then logged in in the context of your account, they will not be blocked by the External Identity Interactions setting. This is the recommended method for enabling legitimate use cases where an entity in one account needs to access a resource in a different account, since it gives you precise control over which identities can log into your account and which profiles they can assume.
To assist users in ensuring that no desired flows are blocked, the setting has a monitoring-only value that allows users to monitor and address existing cross-account flows before fully enabling the setting. It’s recommended that users enable the setting in monitoring mode for 30 days and address any cross-account flows found. There are legitimate reasons why users may be using cross-account flows such as when automation in one account is deploying an application in another account. These flows can be addressed by either using a trusted profile in the target account and allowing an identity in the source account to assume it, by explicitly granting a service ID in another account policy to do the desired actions in your account, or by using the account allowlist provided as part of this feature, which enables you to allow users who are logged in to specific other accounts to access resources in your account that they have access to. The allowlist is especially useful in Enterprise account structures or other situations where multiple accounts are owned by the same organization and the users and resources in those accounts need to interact with each other. Once all desired cross-account flows have been addressed, it is then recommended that you enable this setting in all accounts. For more details see here. There are some limitations on the services that support this setting. For limitation details see here.
There are additional recommended settings and best practices that can help you make sure your cloud account is enabled for maximum security. These are discussed below. While some of these may not be needed on a small account with only a few users, in accounts with many users these settings can help ensure that a mistake by one of your users won’t compromise critical resources in your account.
Domain Restrictions
Domain restrictions allow you to specify the email domains of users who can be invited to your account. This allows you to ensure that only users from your company or specific partners or ISVs can be added to your account, and if you use federation to authenticate your users, it allows you to restrict your account to users in your federated domain if you desire. If one of your users were compromised due to a leaked password or key, this would prevent an attacker from being able to add themselves to your account to continue to gain access once the leaked credential is addressed. Read more details here.
Restrict API key creation
When this setting is disabled, any user can create an API key that will allow them to authenticate to your account as their user, with the full set of permissions granted to their user. It is recommended that you enable this setting to limit users who can create personal API keys to those who have been specifically granted that permission. Users will then be required to create service IDs, grant them a limited set of permissions, and use the service ID’s API key for programmatic access, limiting the access that an API key has. Read more details here.
Restrict service ID creation
With this setting disabled, any user can create a service ID, grant it any access that user has the ability to grant, and create an API key that will allow them to authenticate as that service ID. When the setting is enabled, only users who have been specifically granted permission can create service IDs and their API keys. Read more details here.
Restrict IP address access
This setting allows you to specify a limited set or range of IP addresses that users can access your account from. In simple situations where all account access should be done from a well-defined set of IPs, you can use this setting to restrict access account-wide. In more complex situations where you want to limit access on a per-service basis, or limit access based on endpoint type, the use of Context-Based Restrictions is recommended instead of this setting. Read more details here.
Use Context-Based Restrictions
Context-based restrictions allow you to specify the context, such as source IP addresses and endpoint type, that can be used to access cloud services.
To start using Context-Based Restrictions, first define the network zone(s) that you want to allow traffic from. You can set up multiple zones that can each access different things. Zones can be defined by a set or range of IPs, a VPC, or an IBM Cloud service that you want to allow to access your resources.
Once your network zones are defined, you can create CBR rules. You can select the service(s), resources, and which types of APIs the rule applies to. Next, you can select the context specifying whether the resources and APIs that the rule applies to can be accessed from certain network zones you defined previously, only from certain types of endpoints, or only when certain types of MFA have been performed.
It is recommended that you configure CBR rules for all services in your account to ensure that only people in networks you know are able to try to access your account and that your company’s requirements around MFA and use of private endpoints are met. Read more details here.
Require Multi-factor Authentication
One of the most important settings you can use to improve the security of your account is to require MFA for all users. When MFA is required, even if one of your users leaks a password an attacker would be unable to use that credential to access your account.
There are multiple methods you can use to require MFA. If all of your users are IBMid users and you do not use AppID or have legacy SoftLayer users, you can use MFA for users with IBMids. You can specify whether IBM Cloud should prompt all users for MFA, or only those users who are not federated. If your federated Identity Provider implements MFA, this allows you to avoid an additional MFA prompt for those users who have already performed MFA in your Identity Provider. This method allows users to use any form of MFA supported by IBMid.
If you want to require MFA for all users, and want control over the form of MFA that is required, you should use MFA for a user with or without an IBMid. This will allow you to require MFA for all users and allow you to require specific forms of MFA, including U2F which provides the highest level of security. When users who are members of multiple accounts log in, they will be prompted for the highest level of MFA required by any of their accounts. This ensures that if you require a high level of MFA, users can’t log in with a lower form of MFA in another account and then switch to your account. Read more details here.
Rotate API keys regularly
It’s a best practice, and required by many compliance programs, to periodically rotate all API keys in your account. In case an API key is compromised, this limits the period of time that an attacker could use that key. It also requires you to be aware of all your API keys and where they are being used. To perform key rotation, a new key for each identity in the account that requires an API key should be created. Each application or use case that uses a key should have the old key replaced with the new one. Once all uses of the old keys have been changed, the old keys should be deleted. Secrets Manager can help with management and rotation of IBM Cloud API keys.
Disable API Keys if a compromise is detected
One of the most common ways that API keys can be compromised is when a user inadvertently includes an API key in code that is checked into gitHub. If this occurs, gitHub will notify IBM Cloud. At the time that the API key is created, the creating user can specify what action should be taken if the key is detected to be compromised - disable it, delete it, or do nothing. It is strongly recommended that you require users to always select delete or disable compromised keys. While this may result in a temporary outage of your workload, it will prevent a security breach and force the user to rotate the key and fix the issue to restart the workload rather than have a silent security issue that you may not know about until it is exploited.
Use Trusted Profiles with Compute Resource Identities for application access
In the past, if an application needed to call cloud APIs, an API key had to be configured in the application to allow the application to authenticate. This meant that the key needed to be managed, stored securely, rotated on a regular basis and when a user who had access to it left the team, and deleted when no longer needed. Now, for applications that are running on IBM Cloud VPC VSIs or managed kubernetes or OpenShift, those compute resources can be added to a trusted profile, allowing them to authenticate and assume the profile and its permissions. The application can make an API call to retrieve a short-lived token associated with its compute resource, eliminating the need to store and manage API keys. Read more details here.
Use Secrets Manager
If applications need to store and manage credentials and other secrets, it’s recommended that they use Secrets Manager to store them securely. If an application running on IBM Cloud uses their compute resource identity to access Secrets Manager and configures CBR rules to only allow Secrets Manager to be accessed from the application, and then stores all other credentials and secrets it needs in Secrets Manager, this is a very secure way of managing keys. Secrets Manager can also help with ongoing API key rotation for the API keys it stores. Read more details here.
Use Trusted Profiles or Access Groups to manage access
IBM Cloud supports fine-grained access policies that can be assigned to any type of identity. In order to keep your access policies easy to understand and manage, it is recommended that you always use Access Groups or Trusted Profiles to assign policies; never assign access directly to a user or service ID. This allows the Access Groups and Trusted Profiles to essentially function as “roles” - sets of permissions that are needed by users to do a particular job. Users can belong to multiple Access Groups or be allowed to assume multiple Trusted Profiles if they need multiple sets of permissions.
When using Access Groups, users must be added to the account, and then can be granted permissions by adding them to an Access Group. Note that Access Groups do not support classic infrastructure permissions - if you use classic infrastructure you would need to separately assign those permissions to each user. When you use Trusted Profiles, it is not necessary to add users to each account. You can grant a federated user dynamic access to assume a Trusted Profile based on their SAML rules, or you can grant a user or service ID in another account the ability to assume the Trusted Profile. This makes Trusted Profiles ideal for users with enterprise account structures with multiple accounts who don’t want to have to add and delete users across many accounts and would prefer to manage their users and access in their own Identity Provider or in a centralized account within the enterprise. Trusted Profiles also do include the ability to assign classic infrastructure permissions. There are a few services that do not yet support Trusted Profiles, including Support Center, ROKS, and watson X services. For more details on access groups see here, and for trusted profiles see here.
Follow principles of least privilege
An access policy can grant an identity very fine-grained access to do only a specific set of actions on one or a small set of resources, or it can be very broad, giving permission to do a wide range of actions across many services and resources. It is recommended that you structure your Access Groups and Trusted Profiles so that they have the minimal set of actions on the minimal set of resources required. If the predefined IAM roles include more actions than users require for their job responsibilities, you can define custom roles that include the precise set of actions needed. You can then set access tags on the resources, or use other resource attributes such as resource group or service, to group the precise set of resources you wish to give access to in the policy. This ensures that your users don’t have excessive privileges that could be inadvertently used by your user to misconfigure resources in your account, or leveraged by an attacker to extend the scope of an attack and damage your account or create back doors to give themselves long-term access. For more details on custom roles see here.
Use Conditional Policies
Conditional Policies can further limit the permissions granted by a policy, allowing resources to be accessed only during certain days or hours, or being used to create a temporary policy that will automatically disallow access after a period of time has passed. Any policy that can be created, whether for a specific identity or a Trusted Profile or Access group, can have time-based conditions associated with it that will limit the times that it will grant access. Find more details here.
Don’t log in as the account owner
The owner of an account has full permissions on all resources in the account. This makes the account owner’s credentials and tokens very valuable to an attacker. To prevent compromise of these credentials, and to avoid inadvertently doing a destructive action, do not routinely log in as the account owner and do not create API keys for the account owner. It’s recommended that the account owner be a functional ID that could be transferred to another person if the original account owner leaves their job role, and that each user uses their individual ID or a trusted profile to log into the account unless account owner permissions are specifically needed.
Use IAM Insights to periodically review identities and access
The IAM Insights feature allows you to see users, API keys, and access policies that have not been recently used. You should review these periodically and delete any unneeded identities, credentials, and access so that they can’t be used by attackers to try to gain access to your account. See details here.
Use enterprise IAM templates to manage accounts consistently
If you have an enterprise account structure, enterprise IAM templates allow you to manage account settings, Access Groups and Trusted Profiles, and policies from the enterprise account, then push them out to all or a subset of the accounts in your enterprise. This helps you maintain consistency across all the accounts in your enterprise and ensure that your organization’s policies are being followed across a large number of accounts and users. Read more details here.
Log and Monitor platform activity to detect problems
You can use the IBM Cloud Logs and IBM Cloud Logs Router services to log and monitor platform activity and configure alerts in case suspicious activity occurs. To do this, create an instance of the IBM Cloud Logs service and configure it with Cloud Object Storage buckets to store the logs. Next, configure IBM Cloud Logs Router to send platform logs from all regions to this instance of IBM Cloud Logs (or alternatively, you can have multiple instances of Cloud Logs and segment the logs by region). In the Cloud Logs service you can configure alerts for a variety of conditions so that you will be alerted when unusual activity occurs. If your organization uses a SIEM solution it is also possible to configure your SIEM to analyze the IBM Cloud Logs platform logs and discover anomalous behavior. Find all the details here.
Consider using SCC Workload Protection to monitor your account configurations
SCC Workload Protection allows you to scan your accounts to ensure that your account and all of your resources are configured in the desired way according to your organization’s policies. This helps you to prevent configuration drift, or security vulnerabilities due to changes that you were unaware of. You can configure SCC Workload Protection with the desired profile, and it will then regularly scan your environment and notify you of any misconfigurations that could compromise your security and compliance. Get started here.
IBM Cloud is designed and built with security in mind to meet the needs of the most security-sensitive enterprise customers. Following these guidelines will ensure that you’re leveraging the recommended security features to manage your accounts with maximum security.