Error trying to assign access to the same role

[jinvanstee]

Following this doc to create IAM roles and service ID's for pkcs11 access: https://cloud.ibm.com/docs/hs-crypto?topic=hs-crypto-best-practice-pkcs11-access

I have created two roles following the documentation:

• key operator

• keystore operator

Then I created the SO user service ID.

I was able to assign both key operator and keystore operator to the SO user service ID as documented.

However the next section it asks me to only assign key operator to the SO user for private keystore access. But this was already added in the previous assign access workflow. So when I try to add again I get the following error message:

Access could not be assigned. "The policy wasn't created because an access policy with identical attributes already exists. Please update the roles in the existing policy (37b892da-b353-4aaa-bdc7-e6eb7566b0d1), or update the one you're trying to assign to include a different attribute assignment." 
(Code: c3dc655c-20e0-49f6-ad8e-8d2e82b1174b)

Similar error is seen when assigning the same role key operator the second time to the Normal user.

How is it distinguishing between access to public keystore vs access to private keystore?

[TiffanyLiIBM]

@jinvanstee Thanks much for contacting us and providing your feedback! Based on the latest info we got from the dev team, the private/public keystore has not been supported yet. We've made some changes to the doc to reflect it: https://cloud.ibm.com/docs/hs-crypto?topic=hs-crypto-best-practice-pkcs11-access.

What you need to do now is to:

1. Create custom roles
2. Create service IDs
3. Assign roles to the service IDs

Please let me know if you still have any questions/issues. Thanks!

[jinvanstee]

Thanks @TiffanyLiIBM for the quick response. As it stands right now, the Anonymous user and the Normal user have the same level of access, both able to access the private and public keystores via the key operator role. Is this correct?

[TiffanyLiIBM]

@jinvanstee Sorry for responding to you late. Here is the reply from our developer:

If a client would like to log in as an SO User, the client can use any API key (SO, Normal, or Anonymous). If a client would like to log in as an Normal User, the client can use any API key (SO, Normal, or Anonymous). If a client would like to remain as an Anonymous user (no login), the client can use any API key (SO, Normal, or Anonymous).

The IAM development is now in progress, which should be supported very soon. Will update the doc with the latest info when it is done. Thanks!

[jinvanstee]

Thanks @TiffanyLiIBM. I'm concerned about the following scenario and I'm not sure if the above development activity will address this.

The system administrator has access to the grep11config.yaml file, and hence can "steal" the Anonymous user's API key. Right now the Anonymous user and the Normal user have the same level of access (they are both assigned the key operator role following the PKCS11 IAM setup guide). So with the Anonymous User's API key, the system administrator can also access the private keystores to potentially conduct malicious activities.

Will IAM development provide a different role, that only has access to public keystores, for the Anonymous user?

[liuxjep]

@jinvanstee Hi Jin, Tiffany is on vacation today. I'll try to answer the question. Yes. After the IAM is fully implemented, you can assign different user types (API keys) the corresponding roles to access public keystores or private keystores. Hope this helps.