[Feature] Get/Set client-id through commandline

[ryansteakley]

Description of changes: Allows for client id to be set via an ENV variable; also allows for user to get current client id Added new command to support calling of internal function get_client_id so that user can see the client id that has been configured.

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

[arjkesh]

What is the user experience for setting a static client ID? Is it sufficient to to just use the new --set-client-id?

[ryansteakley]

Once --set-client-id is used the new client id will persist as long as the client-id file is not erased or --set-client-id is used with a new client id

[surajkota]

Making it easy and okay to spoof clients feels like a short term solution that violates the point of having this id and subverts being able to trust this value

Client-id is not a sufficient condition for trust/identity management. At minimum system needs to support identity and access authentication(IAM) for which anubis does not have support today.

Let's take the case when IAM is added to anubis, user/customer will still need this method to set/get their identity. Here is the user story:

As a user, I would like to use the system from anywhere (EC2, docker container, Mac) and dont want to generate new ID for myself everytime I change my platform.

Take the example of AWS, IAM user/role both have an associated name. It is set automatically when you set SECRET_KEY and SECRET_ID and remain the same user/role anywhere you go as long as you use the same credentials. See awscli get which allows getting SECRET_KEY and SECRET_ID. This PR is just enabling that.

It is upto the system developer on how to handle IAM this but at high level get/set ID is still required.

Can we articulate what the problem is that needs to be solved

We discussed this offline and I have given the user story above which I feel is sufficient. In addition to that, some more use-cases which we solve with this PR(i.e. access to client-id) in present state of anubis:

• fetch the logs of an automated nightly job triggered via codebuild
• purge/cancel jobs stuck in pending state which are generated by automated system
• list jobs in past 24 hours and double-click to examine some of them, how many client-id will user need to switch to get logs for each of them

There might be more than one way to solve these problems but based on the first half of this comment, I dont see a problem with this PR