IAM access group policy not enforcing MFA on sensitive APIs for finance users in production

Cloud Platforms IBM Cloud
, , , , , , , ,
1

We’re having issues with IAM access group policies not enforcing MFA on our sensitive API endpoints. We’ve configured policies that should require MFA for certain API operations, but users in the access group can still call these APIs without being prompted for additional authentication.

Here’s our current policy structure:

{
  "type": "access",
  "subjects": [{"attributes": [{"name": "access_group_id", "value": "AccessGroupId-xxx"}]}],
  "roles": [{"role_id": "crn:v1:bluemix:public:iam::::serviceRole:Manager"}]
}

The policy should enforce MFA for API access, but it’s not working as expected. We’ve tested this across development and staging environments with the same results. Is there something wrong with our policy syntax, or is there a specific attribute we need to add for MFA enforcement on API calls? This is critical for our compliance requirements.

2

Let me provide a comprehensive solution addressing all three aspects of your challenge.

IAM Access Group Policy Syntax: Your policy structure is correct for granting access, but MFA enforcement isn’t configured within IAM policies themselves. Policies define what resources users can access and what actions they can perform, not how they authenticate. The policy you’ve shown grants Manager role access but doesn’t include authentication requirements.

MFA Enforcement for API Access: MFA in IBM Cloud applies to user logins (console/CLI), not to API keys or service IDs used for programmatic access. This is by design - automated systems can’t perform interactive MFA challenges. For your sensitive APIs, implement Context-Based Restrictions (CBR):

{
  "resources": [{"attributes": [{"name": "serviceName", "value": "your-service"}]}],
  "contexts": [{"attributes": [{"name": "networkZoneId", "value": "your-zone-id"}]}]
}

CBR rules restrict API access based on network zones (IP ranges), ensuring API calls only come from trusted locations.

Policy Propagation Between Environments: For consistent enforcement across dev, staging, and production:

  1. Use Terraform or IBM Cloud Schematics to define IAM policies as code
  2. Implement identical CBR rules in each environment
  3. For API keys, use separate service IDs per environment with minimal scopes
  4. Enable Activity Tracker in all environments to audit policy compliance

Best practice: Replace long-lived API keys with trusted profiles for compute resources. Trusted profiles generate short-lived tokens automatically, eliminating the need for stored credentials. Configure them to assume specific IAM roles, giving you the security benefits of temporary credentials.

For true MFA on sensitive operations, consider implementing application-level authentication with IBM App ID, which supports MFA flows even for API calls through OAuth/OIDC tokens. This gives you programmatic MFA where IBMs IAM doesn’t apply.

Verify your setup: Check Activity Tracker logs for authentication events, review your CBR rules are active, and audit which service IDs have access to sensitive APIs. Rotate all API keys and implement a 90-day rotation policy.

3

This all makes sense now. Let me clarify the complete solution based on everyone’s input.

4

That’s the key distinction - API keys and service IDs don’t use MFA by design since they’re meant for programmatic access. If you need stronger authentication for sensitive APIs, you should implement context-based restrictions (CBR) rules. These allow you to restrict API access based on network location, IP addresses, or other contextual attributes. You can also use API key rotation policies and limit the scope of API keys to specific services.

5

We faced a similar compliance challenge. For sensitive operations, we implemented a two-tier approach: user accounts with MFA for interactive access, and tightly scoped service IDs with IP restrictions for automated processes. We also enabled Activity Tracker to audit all API calls. The key is treating API keys as secrets and rotating them regularly. For cross-environment consistency, make sure your CBR rules and IAM policies are deployed through automation so they’re identical across dev, staging, and production.

6

Thanks for clarifying. I’ve checked the account settings and MFA is enabled at the account level. However, users can still bypass it when calling APIs programmatically. Is there a way to enforce MFA specifically for API access versus console access? Our concern is automated scripts using API keys without the additional authentication factor.

7

IAM access group policies don’t directly enforce MFA at the policy level - MFA is configured separately through account settings. You need to enable MFA requirements in your account settings first, then configure which authentication methods are required. The policy you’ve shown grants access but doesn’t control authentication methods. Check your account-level MFA settings under Manage > Access (IAM) > Settings.

8

Another option is using trusted profiles with compute resources instead of long-lived API keys. Trusted profiles automatically generate short-lived tokens for your workloads without requiring API keys. This gives you better security since the credentials expire quickly and can’t be extracted. Works well with containers and virtual servers.