Forum Discussion
API service accounts for Fabric API?
Currently I'm using the API token associated with my personal login to Equinix for the Fabric API. What's the best way to make an API token for a service sharable by a group of people at my company? Should I just make an Equinix login like first name Cloud last name Fabric, and then make an API token from that, or is there another way?
nickzxcv Perhaps the safest option would be to use a real team leader's first and last name, use "Fabric Cloud" for the local name. The email address must be a real email address, plus-suffixes are nice. A better choice may be to use a team email address that is independent of individual team members, ultimately delivered to responsible team members. I would not want to build a solution that relies on a workaround that a reasonable and well-meaning service rep or bot would interpret as "delete me".
I would also assume, that as the user and account holder, I would ultimately be responsible for the actions of any system or individual utilizing these credentials and the access delegated to those credentials.
nickzxcv, yes. With that account, login and create an App at https://developer.equinix.com.
This App will provide you with a Client ID and Client Secret which can then be used for OAuth Client Credential token exchanges. These short-lived, refreshable, tokens will have all the rights and privileges of the shared / surrogate account. Store the Client Credentials in a team-shared credential management system (Vault, 1Password, etc).
https://developer.equinix.com/docs?page=/dev-docs/fabric/overview will walk you through the steps to create and use the App and Client Credentials.
Ok, so is this the right way to do it? This kind of shared account user can't have any government ID or legal name in the way it says there.
Then I login to developer.equinix.com with that user and create the API client credentials?
nickzxcv Perhaps the safest option would be to use a real team leader's first and last name, use "Fabric Cloud" for the local name. The email address must be a real email address, plus-suffixes are nice. A better choice may be to use a team email address that is independent of individual team members, ultimately delivered to responsible team members. I would not want to build a solution that relies on a workaround that a reasonable and well-meaning service rep or bot would interpret as "delete me".
I would also assume, that as the user and account holder, I would ultimately be responsible for the actions of any system or individual utilizing these credentials and the access delegated to those credentials.
