Management keys are associated with users, and the key can be used to access whatever that user can access. We have multiple environments and multiple apps, as well as outside contractors that do development work for us.
How do I segregate my Contentful management keys so that a contractor with a certain key can’t access applications that they shouldn’t? Is the only way to create multiple Contentful users that are associated with certain applications? It doesn’t sound ideal.
Is there a way to assign permissions for a management key that are specific to a space? For instance, I would like to create a management key from an admin user that can only operate on my DEV and TEST spaces and use that one for all my scripts.
You are correct and Personal Management tokens are created on the basis of each personal account within Contentful, as explained in the following link:
The permissions to create/edit/delete content in a given space are directly related to the role of the user in each of these spaces.
In your example, it would actually be possible to give an user access to your DEV and TEST spaces, give him an admin role, and utilize the Management token from his account.
An additional possibility would be to use an OAuth token, which may be a great idea if you are creating an application intended for re-use by other Contentful users.
I’m also pinging @charlie or @pedro.carvalho if they have some other ideas of what could be implemented in this case.
Hope this helps
You’re right, @gabriel.
Since a CMA token represents a user, I believe @dustin.aleksiuk can achieve the desired effect by managing contractor’s roles in each space. The one thing to keep in mind is that those contracts shouldn’t be admins, otherwise they’ll have full access.
@dustin.aleksiuk does that make sense to you, or am I missing something?
Thanks for the response. I’m pretty sure I understand. It’s not ideal because we would like to have generic users for the scripts that promote content model changes across environments. It’s tricky to manage these permissions in a company like ours because we would prefer to not use “real” users for automated scripts. We have an operations user that is an admin on these spaces, but I don’t like that the same key can be used across many spaces. It’s hard to hide the management key since the scripts need it to run.
I think we’ll have to use a real user account key for now and then revoke it once the project is in production and the outside contractors have all moved on.
One other thought I wanted to add to this is that you could generate many different CMA tokens all representing the same user (and the same access to spaces) and use one for each script or project. Then you can revoke each token when no longer needed.
That’s a good point. We should do this. It doesn’t eliminate the issue of having management keys floating around but it does allow us to revoke them. I think the solution is probably to have a “prod” admin user and a “non-prod” admin user. Thanks for that response.