Run opendistro alerting plugin background jobs securely

[skkosuri-amzn]

Background

Also refer to issue (#6)
OpenDistro plugins have background jobs which run periodically, like alerting monitors. This issue explores approaches to securely run these jobs.
Consider below sample configuration:
OpenDistro Roles : ops_role, hr_role
Mapping Role to Index :
-ops_role index_permissions has app_logs_index.
-hr_role index_permissions has salaries_index.
Users: chip_user,dale_user

• chip_user is part of IT operations team and can access only app_logs_index, he is
  assigned ops_role.
• dale_user is part of HR department and can access only salaries_index, so he is assigned
  hr_role.

Approaches:

Option 1: ImpersonateUser

1. Store the user who created the alerting monitor as part of the monitor configuration.
2. When the alerting monitor runs, its assumes the user from monitor configuration and runs
   the search.
3. Alerting monitor created by chip_user can search only app_logs_index and
   can't search on salaries_index. Similarly, monitor created dala_user can't search app_logs_index.

Pros:

1. Access permissions for the user can be enforced both at monitor create time and monitor periodic runs.
2. If the user permissions change after monitor is created, this method handles it. For example: chip_user had admin_role when he created monitor and latter has only ops_role.
3. We can configure to show only monitors, destinations, alerts for that user in kibana. And admin can see all monitors, destinations and alerts.

Cons:

1. When a user leaves the organization, the monitor runs fail. Admin user has to
   explicitly move the monitors from chip_user to mickey_new_user.

Option 2: RolesInject (a.k.a ImpersonateRole/AssumeRole)

1. Store the opendistro roles of the user who created the alerting monitor as part of the monitor configuration.
2. When the alerting monitor runs, its assumes all the roles from monitor configuration and runs the search.
3. Alerting monitor created by chip_user can search only app_logs_index, since chip_user has ops_role when its created.

Pros

1. Solves the delete user issue from option#1. When chip_user leaves the organization, the monitor continues to run as long as the ops_role is present.

Cons

1. All the roles of the user who created monitor have to be stored as part of configuration.
2. Can't handle if user permissions change after the monitor is created. Handles only the role
   permissions changes. For example: chip_user had admin_role when he created monitor and latter has only ops_role. Monitor will continue to run with admin_role.
3. We can't configure to show only monitors created by user in kibana.

[smlx]

Option 2 definitely sounds better to me. Option 1 sounds much too fragile since users are likely to come and go, but roles will be more permanent.

[fbarbeira]

I agree with smlx.

In our configuration most of the alerts are shared between users who are in the same department (role). If security are user-oriented we will be duplicating alerts. And looks like administration will be easier with alerts role-oriented.

[skkosuri-amzn]

Thanks. Tagging more folks to comment @fabiocorneti @contato318 @MedoDome @nborisenko

[MedoDome]

Hey hey,

I agree with smlx and fbaberia.

Monitors should be connected with roles because users are sharing data between each other inside groups/tenants.

If the user losses his role to his tenant/group, he/she should lose access to the created monitor.

[skkosuri-amzn]

Thanks for the feedback. Adding @dinusX @hardik-k-shah to this discussion.

[skkosuri-amzn]

@jimishs

[hardik-k-shah]

Option#2 makes more sense. As roles is the final entity who will provide authorization. Additionally, in option#1 if user role gets changed, all his/her monitor will stop running. Lets say an example where chip move to another team and his role changed. Now all monitor configured by chip will suddenly stopped working (unless it is properly handled and moved/copied to some other user). Option#2 gives protection against this.

For option#2 Cons #1 and #3 can be fixed.

1. All the roles of the user who created monitor have to be stored as part of configuration.

We can ask user explicitly, which role user want to create alert/monitor with. You can fetch all available role (assigned to user through account API and show them in drop down on kibana. User can choose specific role to create a monitor. There is a dry run option to validate if monitor has required permission to run.

3. We can't configure to show only monitors created by user in kibana.
   We can also store user who created monitors along with role. User can be use to just filter all monitor created by given user to display/manage monitors in kibana.

Additionally, we can safely say Impersonate Role as Assume Role functionality. For this use case, as background job is running as super admin, we can say super admin always have permissions to assume any role and scope down the permissions. And this approach can be extended to any background job which is going to run as admin but need to scope down the permission to run as limited permission set.
Additionally, Assume Role functionality can be extended for admin user as well which will help admin to dry run and validate permissions of any new role he/she is creating before assigning it to actual user. (or can be use for debugging purpose as well)

[hardik-k-shah]

@lucaswin-amzn What are your thoughts?

[skkosuri-amzn]

@hardik-k-shah Thanks for the detailed comments.

---

On "asking user explicitly to select which role he wants to use to create alert monitor with". I see couple of challenges:

1. User have to be ware of the roles that are needed. Most of the cases, I see admin's are aware of roles and they assign roles to users. If user needs to select the role, we adding additional UX overhead?
2. Current API signatures have to be changed to take the selected roles. We are mixing security with business logic?
   Perhaps, we can look into in the latter phase?

---

Yes, agreed on the "super admin always have permissions to assume any role and scope down the permissions."

[mogul]

For (1) above I think the users who are that unsophisticated probably only have one role available. If there's only one role, then don't make it a drop-down select, just show that one role as unconfigurable in the form. That will make the UX relatively unchanged for them, in terms of the number of things they have to know/set in order to submit.

On (2) I don't understand the concern... Can you elaborate on how you think scoping alerts to roles would be conflating security and business?

[skkosuri-amzn]

@mogul Thanks for the comments.
For first phase, I am thinking - we will copy all the roles user has and save it. In second phase, provide UI to select/modify the roles.

[skkosuri-amzn]

FYI @praveensameneni

[CarlMeadows]

Can we add this to the roadmap - which release is this planned to be available for the Alerting plug-in?

[skkosuri-amzn]

Can we add this to the roadmap - which release is this planned to be available for the Alerting plug-in?

Sure. Will do.

[skkosuri-amzn]

Available in version 1.11

[skkosuri-amzn]

Hi all,
We are going to demo and discuss Alerting Security in coming ODFE Community meeting on 11/16/2020/
Invite: https://opendistro.github.io/for-elasticsearch/blog/meetings/2020/11/community-meeting-late-nov/

See you soon.
thanks