Step-by-Step Guide: Removing Unused IBM Cloud Policies

Access policies in IBM Cloud specify who obtains which set of privileges on which resources. “Last-permit” data is updated when a policy is reviewed and then applied to authorize access. That information can be utilized to identify unused or inactive access policies.

This blog post provides an overview of the various IBM Cloud access policy kinds. Then, we’ll show you how to retrieve information about inactive access policies and talk about how to use that information. This will show you how to wipe away unused policies in order to improve security in your IBM Cloud environment:

Policies Regarding Access

Access policies define who has access to which resources in IBM Cloud Identity and Access Management (IAM). There are two types of policies in general: access and authorization.

• The authorization type is used to allow access to one service to another. Allowing a storage or database service (for example) to access an encryption key from IBM Key Protect for IBM Cloud is an example policy.

• The access type influences resource access for all identities in an access group or for specific IAM identities (e.g., a user, service ID, or trusted profile). A typical policy would offer an access group reader and writer role to an IBM Cloud Object Storage instance’s storage bucket. Another example would be to offer a specific user administrator privileges in the account for user management.

Policies might be very narrowly scoped, granting just chosen privileges on a given resource. Access is granted to all instances of the same service type or to all resources in a resource group or area under more general policies. Policies could even contain time constraints. In my previous blog post, “For a limited time only: Time-based restrictions for enhanced cloud security,” I discussed them.

The image above depicts the IBM Cloud console when updating the specifics of an access policy for an access group. It enables Viewer and Reader access to all identity- and access-enabled services in the resource group “cloudsec-workshop.” Furthermore, access is limited to the time period indicated. The console has a JSON representation of the access policy. The following screenshot depicts a portion of the JSON object for the previously stated sample policy:

Determine unused access policies.

As previously stated, access policies specify resource privileges for members of an access group, individual IAM identities, or services. When resource access is requested, the policies are reviewed and either no access is provided or a policy that allows access is discovered. That usage of an access policy is documented in IBM Cloud with both a date as last_permit_at  and a counter as last_permit_frequency.

That data can be used to audit access policies and identify inactive policies. Policies that have been dormant for 30 days or more are listed in the IBM Cloud console. It does not display policies that are completely unused.

The IAM Policy Management API provides an alternative to the IBM Cloud console. When the format parameter is set to include_last_permit, it allows you to obtain all policies and include the “last-permit” attributes in the result sets. We created a simple Python program to help with API interaction and to provide some filtering and data output as JSON or CSV data. The utility is accessible on GitHub under the name ibmcloud-iam-keys-identities. The README file contains instructions on how to access the policy data.

The tool output in JSON format for an infrequently used and inactive access policy is shown below. It is part of an IAM access group (subject) and allows Viewer access to a specified resource group in an IBM Cloud account:

Control inactive policies

Once you’ve compiled a set of policies, the next question is how to maintain them. In general, you should investigate their nature (access or authorization) as well as the type and role of the privilege issued. Is the permission limited to a single service instance or very broad (for example, on a resource group or all instances of a service)? Is it a role with limited or broad access, such as Manager or Administrator?

Considering the concept of least privilege, it may be necessary to adapt and reduce granted privileges. It is also a good time to double-check that all policies have a thorough description. Descriptions are optional, but as a best practice, they should be utilized to simplify administration and improve security. Be aware of service-to-service authorizations that allow cross-account access for resource sharing, as well as policies that involve trusted profiles:

• Currently utilized policies: You should probably maintain them because they were designed for a reason and are now in use. However, you should consider whether they were defined with very broad privileges.

• Policies that have been inactive for 30 days or more: You should explore why the policies are in place. Perhaps they are only utilized for rare tasks? If you haven’t already, you should think about limiting the regulations with time constraints. As a result, they can only be used during the time period specified. Another thing to look into is whether the policy is limited to past dates.

• Policies that have never been implemented: These should be investigated. Who made these and why did they make them? Why were they never put to use? There could be both good and bad causes for this.

To improve security, eliminate any policies that are no longer required. Depending on how you examined policy details—via the IBM Cloud console, the CLI, or the API—you want to stay in the same environment and erase obsolete policies. Although all policies can be retrieved with a single API query or listed inactively in a single list in the console, removal is dependent on the policy type and subject. In the console and CLI, each has its own command.