Can read, but can't create - but the perms say I should be able to?

Options
bortels
bortels
Community Member
in Secrets Automation

Hey, trying to ship secrets from AWS Secrets Manager to 1password for human consumption, and - I can't seem to create. Can read from 1password fine, but on create I get:

onepasswordconnectsdk.client.FailedToRetrieveItemException: Unable to post item. Received 403 for /v1/vaults/tobpp5worysamh765snazsueba/items with message: Authorization: token does not have permission to perform create on vault tobpp5worysamh765snazsueba

I double checked that the vaultid is correct, and that the permissions in the integration are set to "Enable All" (which shows as "read, write" not "Full Access" like a human does, which seems odd).

I even tried making a new token after setting the permissions to all. No joy.

I guess I'm trying to work out where to go next with debugging. Any advice appreciated. I am going to try to get a minimal curl version working to exclude the SDK from being the cause.

client is python 3.7.9 using the onepasswordconnect sdk. current API containers running under docker.

1Password Version: Not Provided
Extension Version: Not Provided
OS Version: Not Provided
Sync Type: Not Provided

Comments

  • bortels
    bortels
    Community Member
    Options

    Well, that was silly - posting here in case someone else has the same issue.

    When you create a token = it does not inherit the permissions you have in the integration. You need to choose your vaults and go hand-modify each to have the access you want, it defaults to read-only. So - if you modify permissions for your vaults, you need to issue a new token, and you need to hand-modify the perms in that token as you create it.

  • James_1P
    James_1P
    Options

    Hi bortels,

    We intentionally set the token permission to default to read only given the potential destructive nature of depositing a R/W token into unattended infrastructure.

    The inability to modify token permissions after issuance was also a least privilege choice to prevent a different admin from escalating the permissions of a token (also a technical limitation of JWTs).

    We are actively looking to improve the authentication and permission management of parts of Secrets Automation so your feedback on this experience is very valuable

This discussion has been closed.