Protect AWS Credentials

[gisjedi]

Pain Point? Please describe.
Currently when you specify AWS Access Key ID and Secret Access Key for either S3 Workspace or Strike (to authenticate to SQS queue) there is no protection for the ID and Key. Any user that can access the API as a read user will be able to extract the credentials.

Desired Solution
One solution would be to push all credentials into Vault, but this would make it a hard requirement of Scale. Presently, we don't require it by default. It would then be necessary to only make it a one-way update, reading would be restricted to the executing strikes / pre-tasks.

Alternative / Workaround
We could alternatively just lock the API down to only allow read of the credentials when the user has is_staff flag. This would break the UI for the workspace and strike views of non-privileged users.

[JohnPTobe]

Assuming it's not a problem if scale admins can see s3 keys for workspaces/strikes I say we just return 'hunter2' for those fields in the API regardless of who's logged in.

[JohnPTobe]

That displays as ******* for everyone else right?

[gisjedi]

Yeah, just allow GET only of workspaces / strikes for users with is_staff set to False and sanitize the credentials.

[cshamis]

Ideally, admins can set and see. Everybody else gets stars. (To show that it's been set, but you can't see it.)

…

On Sep 1, 2019, at 4:36 PM, Jonathan Meyer ***@***.***> wrote: Yeah, just allow GET only of workspaces / strikes for users with is_staff set to False and sanitize the credentials. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

[JohnPTobe]

I'll sanitize those fields by default in the convert_config_to_v6_json method used by the workplace serializer. Thus you have to explicitly have a flag passed from the api that an admin is requesting the object and if we miss an object that has a workplace as a relation it won't be leaked accidentally.