Break Glass for Slack access

[AlexKantor87]

As a SOC2 compliant business
I would like to have auto approve turned off
But have the ability to have break glass access in case of emergency
So that as standard all privileged access is approved by at least one other person
The break glass should not be root access

Acceptance Criteria
In an emergency situation
A user requests access
But is able to click to approve their own access
This would also notify all of the approvers that self approval was granted

When a user self approves their own privileged access
They should have to provide reasoning as to why break glass was needed
So that other approvers can review this

When a user tries to self approve
There should be a way to check to make sure that this was intentional
And they should have the ability to go back before access is approved

[Andrey9kin]

@AlexKantor87, thanks for the issue. We have been debating this quite a bit in the team.

Generally, we do not recommend having auto-approve on, and most of the deployments I'm aware of have this feature disabled. It is quite easy to get an approval since it could be done via the Slack app on the phone. Responders could send an SMS or call other approvers to ask them to approve the request. Also, usually, if there is a serious outage, you would want to have business leaders notified anyway, so the responder won't be alone.

Today, if self-approval is enabled and the person is an approver, then their request will be approved automatically. There is no place in the flow to provide additional reasons for the self-approval. If we are to implement this, what would it look like?

Do I understand right that you want the button to be always present, and then if the requester presses the button, then he will be prompted with an additional form to fill in his motivation?

[AlexKantor87]

Fair comments @Andrey9kin

The extra comment box is a nice to have and not a must have.

The button to approve but allowed to self approve would have been minimum request. For the situations where a specific set of approves are not available or responding (e.g. middle of the night)

[Andrey9kin]

@AlexKantor87 I think we might want to do the button and extra pop-up form for motivation for self-approval, so it is clear why it happened, plus an additional notification for everyone that there was self-approval. It will be an improvement for the self-approval flow in general. If it solves SOC2 for you, even better. Plus, if we always present the button, it could help simplify the internal logic. What do you think @EreminAnton?

[EreminAnton]

I'm not sure if it's necessary to do an extra pop-up form for motivation for self-approval when a user makes a request. It doesn't matter if it's self-approval or not; the user is forced to fill out the Why do you need access? field in any case, with any type of approval.

After a look at the code, I'm not sure if removing the showing buttons will simplify things. Looks like it will remove only one if show_buttons: statement that optionally schedules discard_buttons_event and approver_notification_event. The rest of the approval logic would move between handle_request_for_access_submission and handle_button_click functions rather than being fundamentally changed or simplified.

I see break glass more as an addition to the SSO Elevator's functionality rather than a refactoring of the existing logic. Something like:

1. We have a Break glass SSO Permission set managed inside the Management account (so no one, even with access to the SSO account, would be able to use it), which has access to the entire AWS org, but is not accessible from the SSO Elevator by default functionality.

2. SSO Elevator has separate logic for handling Break glass access. This request comes to the SSO Elevator, which sends a message to SNS to notify all approvers & maybe anyone else who is in some variable like break_glass_notification_emails. At the same time, it sends a couple of BIG RED messages to the Slack channels (we can add another notification channel, so for example it would send a message to #general so everybody knows). It delays access provisioning for a couple of minutes, allowing someone to use the STOP THIS ACCESS REQUEST big red button.

3. And only after that, access is provisioned to the person. This approach might also help to avoid the need for specific on-call person logic, as we don't need to know who exactly is responsible now, because we make enough noise to alert everybody.

[Andrey9kin]

@EreminAnton, I like your line of thought. So, instead of adding a break glass procedure to the primary approval flow, we would have a separate slash command to invoke it. Do I understand you correctly?

[Andrey9kin]

If it is a separate command, we could add a separate list of people who can invoke it, presumably only responders on duty.

[AlexKantor87]

I'm happy with the separate command and like the thinking of a time gap to enable a "stop this from happening" alert to other users too.

This means we'd turn auto approve off and have this extra break glass.

[EreminAnton]

Yep, I think it would be cool. Maybe it would be better if we could integrate it somehow into the initial form, for example, like the second page. But a separate command will also do the work.

[Andrey9kin]

Okay, let's schedule