August 4, 2023 By Henrik Loeser 5 min read

When was the last time you looked over existing access policies in your cloud account? It’s very likely that it is not on your regular tasks (yet), but it should be done regularly to improve security.

In IBM Cloud, access policies define who receives which set of privileges granted on what resource. When a policy is evaluated and then applied to allow access, “last-permit” data is updated. You can utilize that data to identify unused or inactive access policies.

In this blog post, we provide an overview of existing IBM Cloud access policy types. Then, we show you how to retrieve information on inactive access policies and discuss how to act on that data. This will demonstrate how to clean up unused policies to enhance security for your IBM Cloud environment:

Details of an access policy of an IBM Cloud IAM access group.

Overview: Access policies

In IBM Cloud Identity and Access Management (IAM), access policies specify what access is granted to whom for which resources. In general, there exist two types of policies, access and authorization:

  • The authorization type is used to grant a service access to another service. An example policy could be to allow a storage or database service (instance) to read an encryption key from IBM Key Protect for IBM Cloud.
  • The access type helps determine resource access for either all the identities as members of an access group or for individual IAM identities (e.g., a user, service ID or trusted profile). A typical policy would grant an access group reader and writer role for a specific storage bucket of an IBM Cloud Object Storage instance. Another example would be to grant an individual user the administrator privilege for user management in the account.

Policies can be scoped very narrowly—this means that only selective privileges on a specific resource are granted. More generic policies grant access to all instances of the same service type or to all resources in a resource group or region. Policies could even include time-based restrictions. I discussed them in my recent blog post, “For a short time only: Time-based restrictions for enhanced cloud security.”

The screenshot above shows the IBM Cloud console when editing the details of an access policy for an access group. It grants Viewer and Reader privileges on all identity- and access-enabled services in that resource group “cloudsec-workshop.” Moreover, access is restricted to the shown time range. A JSON representation for the access policy is available in the console. The screenshot below shows the partial JSON object for the discussed sample policy:

Partial JSON object for an IBM Cloud IAM access policy.

Identify unused access policies

As described, access policies define the privileges on resources for the members of an access group, for individual IAM identities or for services. When resource access is requested, the policies are evaluated and either no access is granted or a policy is found that permits access. In IBM Cloud, that usage of an access policy is recorded with both the timestamp as last_permit_at and a counter last_permit_frequency.

You can use that information to audit access policies and identify inactive policies. The IBM Cloud console lists policies that have been inactive for 30 days and longer. It does not show entirely unused policies.

An alternative to the IBM Cloud console is the IAM Policy Management API. It allows you to retrieve all policies and include the “last-permit” attributes into the result sets when setting the format parameter to include_last_permit. We built a small Python tool to simplify interaction with that API and support some filtering and data output as JSON or CSV data. The tool is available in the GitHub repository ibmcloud-iam-keys-identities. See the README file for how to retrieve the policy data.

The following shows tool output in JSON format for an infrequently used and inactive access policy. It belongs to an IAM access group (subject) and grants Viewer permissions on a specific resource group in an IBM Cloud account:

Inactive IAM access policy for an access group.

Manage inactive policies

Once you have the list of policies, the question is how to manage them. In general, you should check on their type (access or authorization) and the type and role of privilege granted. Is the privilege on a specific service instance or very broad (e.g., on a resource group or all instances of a service)? Is it a role granting minimal access or broad, like Manager or Administrator?

Following the principle of least privilege, it might be time to adjust and cut down on granted privileges. It is also a good time to check if all policies have a great description. Descriptions are optional but should be used as a best practice to ease administration and improve security. Be aware of service-to-service authorizations that grant cross-account access for resource sharing and policies involving trusted profiles:

  • Recently used policies: You probably want to keep them because these policies should have been created for a reason and they are in use. However, you might want to check if they were defined with too broad privileges.
  • Policies inactive for 30 days and longer: You should investigate for what the policies are in place for. Maybe they are used for infrequent tasks? If not done already, you might want to consider restricting the policies with time-based restrictions. Thus, they can only be used during the assigned time window. Something to also check is whether the policy is restricted to past dates.
  • Policies that have never been used: These need to be investigated. Who created them and for what purpose? Why were they never used? There could be good and bad reasons.

To improve security, you should delete those policies that no longer are needed. Depending on how you analysed details for a policy—in the IBM Cloud console, or with the CLI or API—you want to continue in the same environment and delete obsolete policies. Although you can retrieve all policies with a single API call or list the inactive ones in a single list in the console, removal depends on the policy type and the subject. Each has its own command in the console and CLI.


Access policies define who receives which set of privileges granted on what resource. They exist in different flavors for access groups, IAM identities and service-to-service authorizations. If access policies become stale and are no longer needed, they pose a security risk and should be removed. The goal is to operate with the least set of privileges.

IBM Cloud offers functionality to identify inactive or unused access policies. We discussed how such policies can be identified and how to handle them. So, when was the last time you analysed your IBM Cloud account for inactive identities?

Get started with the following resources:

If you have feedback, suggestions, or questions about this post, please reach out to me on Twitter (@data_henrik), Mastodon ( or LinkedIn.

Was this article helpful?

More from Cloud

The history of the central processing unit (CPU)

10 min read - The central processing unit (CPU) is the computer’s brain. It handles the assignment and processing of tasks, in addition to functions that make a computer run. There’s no way to overstate the importance of the CPU to computing. Virtually all computer systems contain, at the least, some type of basic CPU. Regardless of whether they’re used in personal computers (PCs), laptops, tablets, smartphones or even in supercomputers whose output is so strong it must be measured in floating-point operations per…

A clear path to value: Overcome challenges on your FinOps journey 

3 min read - In recent years, cloud adoption services have accelerated, with companies increasingly moving from traditional on-premises hosting to public cloud solutions. However, the rise of hybrid and multi-cloud patterns has led to challenges in optimizing value and controlling cloud expenditure, resulting in a shift from capital to operational expenses.   According to a Gartner report, cloud operational expenses are expected to surpass traditional IT spending, reflecting the ongoing transformation in expenditure patterns by 2025. FinOps is an evolving cloud financial management discipline…

IBM Power8 end of service: What are my options?

3 min read - IBM Power8® generation of IBM Power Systems was introduced ten years ago and it is now time to retire that generation. The end-of-service (EoS) support for the entire IBM Power8 server line is scheduled for this year, commencing in March 2024 and concluding in October 2024. EoS dates vary by model: 31 March 2024: maintenance expires for Power Systems S812LC, S822, S822L, 822LC, 824 and 824L. 31 May 2024: maintenance expires for Power Systems S812L, S814 and 822LC. 31 October…

IBM Newsletters

Get our newsletters and topic updates that deliver the latest thought leadership and insights on emerging trends.
Subscribe now More newsletters