What are they?
Platform Service Accounts (colloquially called “robots”) are shell users that select people can access by way of assuming its role. Think of it like a hat that individual users can put on and take off. The hat is not tied to any one individual, and multiple individuals can use it.
From Redshift's perspective the robot is just another Redshift user with a database password and an assigned set of permissions like any other user’s permissions. That Redshift user is linked to a special type of Platform user. Platform allows you to control which individual (“real”, non-robot) Platform users are allowed to assume the role of the robot user.
Why would I want a robot?
Use case |
Problem with using a human user |
How a robot solves this |
A data pipeline has to be kept stable |
When an actual human leaves the company, their account's permissions get revoked and any workflow they owned will break |
Robots can't quit |
Multiple people in an organization want to collaborate on scripts/workflows/tables without repeatedly worrying about ownerships and permissions |
When an individual user creates a table, they are the only person except superusers who can drop/modify that table (and giving everyone superuser status is very bad database management practice) |
The robot user can own everything, and individuals who need to work on the things can do so by assuming the robot's role |
You need to deploy a productionized Service |
As above, if an actual human leaves the company, the services will break. |
Robots can't quit |
Individual users may have access to much more data than is necessary for the app, and that data may be put at risk if the Service is configured poorly. |
The robot user constrains the resources the app can access, which limits the amount of damage done if the application has a security issue |
How do I access an existing robot user?
The requirements for assuming role of a robot are the same as for assuming role of any other user: you must belong to a group which can manage the robot’s primary group. This is something to consider when setting up robot accounts, see more below. If you need access to an existing Robot account, please contact your org’s internal administrators about being added to the appropriate group.
For instructions on how to assume role of a user, and for more information on assuming roles generally, please see our Assume Role Documentation. Note that robots are not allowed to log into Platform directly.
How do I make a new robot?
If you are a Team Admin or Org Admin, then follow the normal process for creating new users and make sure to set the “Robot” flag to true.
Tips:
- For the email address, we recommend using a listserve that multiple users have access to, like 'civis_prod_robot_managers@yourorg.com'.
- It’s best practice to isolate your Robot users within an “<Org> Robots” group. Use this group as the Primary Group for your robot.
- Think about who should be able to assume role of your robot - everyone? only some people?
- If these people are all in an existing group or groups, then make sure those groups can manage the “Robots” group.
- If these people are not all in an existing group(s), or some users need to be excluded, then create an “ <Org> Robot Managers” group and grant it manage permission over the “Robots” group. Add everyone to the group who needs to be able to assume role of the robot user.
If you are not an Admin, then reach out to an Admin within your org for help.
What if I want the robot to do something tricky, like...
access GitHub
You will need a Github account created for the robot as well. Contact your Github administrator with:
- a request for a Github account with the same robot email address as the Platform account
- the repository or repositories the robot will need access to
Once the Platform and Github accounts are created:
- Assume Role of the robot user
- Follow the normal process for connecting a Platform account to Github: How to Connect Platform to Github
access Google Sheets
Google Sheets can be accessed by robot users in one of two ways: using a Google Service Account, or using OAuth with a standard Google Account. Service Accounts are recommended, as they are Google’s corollary to Platform robots.
- Use a Google Service Account:
- Ask your Google Suite manager to create a Google Service Account
- Add the Google Service Account credentials as a Custom Credential in the robot's Platform account.
- Share the Google Sheets with the Google Service Account email, which will end in @[GCP Project name].iam.gserviceaccount.com. Note that the “GCP Project name” section of the domain may differ from robot to robot.
- Follow the standard process for connecting Platform and Google:
- Navigate to a Google Sheets import or export
- Click Update Google authentication
- Confirm the update by clicking Ok
- Choose which account you want to connect
- We recommend using an account specific to the robot user (not a personal account) to ensure the import/export won’t break should a team member leave in the future.
- Click Allow to grant Platform access to the Google Account
Comments
0 comments
Please sign in to leave a comment.