Skip to content

Grant .tasks access to kibana_system role #35573

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Merged
merged 1 commit into from
Nov 15, 2018
Merged

Grant .tasks access to kibana_system role #35573

merged 1 commit into from
Nov 15, 2018

Conversation

tvernum
Copy link
Contributor

@tvernum tvernum commented Nov 15, 2018

Kibana now uses the tasks API to manage automatic reindexing of the
.kibana index during upgrades.

The implementation of the tasks API requires that

  1. the user executing the task can create & write to the ".tasks" index
  2. the user checking on the status of the task can read (Get) the
    relevant document from the ".tasks" index

@tvernum
Grant .tasks access to kibana_system role
1cb2e16 
Kibana now uses the tasks API to manage automatic reindexing of the
.kibana index during upgrades.

The implementation of the tasks API requires that
1. the user executing the task can create & write to the ".tasks" index
2. the user checking on the status of the task can read (Get) the
   relevant document from the ".tasks" index
@elasticmachine
Copy link
Collaborator

Pinging @elastic/es-security

@tvernum
Copy link
Contributor Author

tvernum commented Nov 15, 2018

CC: @epixa , @spalger

@tylersmalley
Copy link
Contributor

I have tested and verified this on the Kibana side by updating the role with the equivalent:

    {
      "names" : [
        ".tasks"
      ],
      "privileges" : [
        "create_index",
        "read",
        "create"
      ]
    },

@s1monw
Copy link
Contributor

s1monw commented Nov 15, 2018

LGTM

nik9000
nik9000 approved these changes Nov 15, 2018
View reviewed changes
Copy link
Member

@nik9000 nik9000 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This'll get the job done until we can fix tasks infrastructure not to need the permissions. Thanks!

@jaymode jaymode merged commit 1e60b28 into elastic:master Nov 15, 2018
jaymode pushed a commit that referenced this pull request Nov 15, 2018
@tvernum @jaymode
Grant .tasks access to kibana_system role (#35573)
3fa42bb 
Kibana now uses the tasks API to manage automatic reindexing of the
.kibana index during upgrades.

The implementation of the tasks API requires that
1. the user executing the task can create & write to the ".tasks" index
2. the user checking on the status of the task can read (Get) the
   relevant document from the ".tasks" index
jaymode pushed a commit that referenced this pull request Nov 15, 2018
@tvernum @jaymode
Grant .tasks access to kibana_system role (#35573)
9d57219 
Kibana now uses the tasks API to manage automatic reindexing of the
.kibana index during upgrades.

The implementation of the tasks API requires that
1. the user executing the task can create & write to the ".tasks" index
2. the user checking on the status of the task can read (Get) the
   relevant document from the ".tasks" index
@LeeDr LeeDr mentioned this pull request Nov 15, 2018
Closed
@tvernum
Copy link
Contributor Author

tvernum commented Nov 16, 2018

Thanks @jaymode

nik9000 added a commit to nik9000/elasticsearch that referenced this pull request Nov 16, 2018
@nik9000
Tasks: Only require task permissions
ef69ce7 
Right now using the `GET /_tasks/<taskid>` API and causing a task to opt
in to saving its result after being completed requires permissions on
the `.tasks` index. When we built this we thought that that was fine,
but we've since moved towards not leaking details like "persisting task
results after the task is completed is done by saving them into an index
named `.tasks`." A more modern way of doing this would be to save the
tasks into the index "under the hood" and to have APIs to manage the
saved tasks. This is the first step down that road: it drops the
requirement to have permissions to interact with the `.tasks` index when
fetching task statuses and when persisting statuses beyond the lifetime
of the task.

In particular, this moves the concept of the "origin" of an action into
a more prominent place in the Elasticsearch server. The origin of an
action is ignored by the server, but the security plugin uses the origin
to make requests on behalf of a user in such a way that the user need
not have permissions to perform these actions. It *can* be made to be
fairly precise. More specifically, we can create an internal user just
for the tasks API that just has permission to interact with the `.tasks`
index. This change doesn't do that, instead, it uses the ubiquitus
"xpack" user which has most permissions because it is simpler. Adding
the tasks user is something I'd like to get to in a follow up change.

Instead, the majority of this change is about moving the "origin"
concept from the security portion of x-pack into the server. This should
allow any code to use the origin. To keep the change managable I've also
opted to deprecate rather than remove the "origin" helpers in the
security code. Removing them is almost entirely mechanical and I'd like
to that in a follow up as well.

Relates to elastic#35573
@nik9000 nik9000 mentioned this pull request Nov 16, 2018
Merged
@ulab
Copy link

ulab commented Nov 28, 2018

Is this a fix for the "Kibana server is not ready yet" problem people had?

Can the user and role that were created as a workaround be removed after upgrading to 6.5.1?

@epixa
Copy link
Contributor

epixa commented Nov 28, 2018

Yep, this resolves the failed saved object migration setup that left kibana in a broken state, as described in the release notes “known issues”. If you used the workaround of manually creating your own kibana system user, you can switch back to the built in user in 6.5.1.

nik9000 added a commit that referenced this pull request Nov 28, 2018
@nik9000
Tasks: Only require task permissions (#35667)
0588dad 
Right now using the `GET /_tasks/<taskid>` API and causing a task to opt
in to saving its result after being completed requires permissions on
the `.tasks` index. When we built this we thought that that was fine,
but we've since moved towards not leaking details like "persisting task
results after the task is completed is done by saving them into an index
named `.tasks`." A more modern way of doing this would be to save the
tasks into the index "under the hood" and to have APIs to manage the
saved tasks. This is the first step down that road: it drops the
requirement to have permissions to interact with the `.tasks` index when
fetching task statuses and when persisting statuses beyond the lifetime
of the task.

In particular, this moves the concept of the "origin" of an action into
a more prominent place in the Elasticsearch server. The origin of an
action is ignored by the server, but the security plugin uses the origin
to make requests on behalf of a user in such a way that the user need
not have permissions to perform these actions. It *can* be made to be
fairly precise. More specifically, we can create an internal user just
for the tasks API that just has permission to interact with the `.tasks`
index. This change doesn't do that, instead, it uses the ubiquitus
"xpack" user which has most permissions because it is simpler. Adding
the tasks user is something I'd like to get to in a follow up change.

Instead, the majority of this change is about moving the "origin"
concept from the security portion of x-pack into the server. This should
allow any code to use the origin. To keep the change managable I've also
opted to deprecate rather than remove the "origin" helpers in the
security code. Removing them is almost entirely mechanical and I'd like
to that in a follow up as well.

Relates to #35573
nik9000 added a commit that referenced this pull request Nov 28, 2018
@nik9000
Tasks: Only require task permissions (#35667)
1502893 
Right now using the `GET /_tasks/<taskid>` API and causing a task to opt
in to saving its result after being completed requires permissions on
the `.tasks` index. When we built this we thought that that was fine,
but we've since moved towards not leaking details like "persisting task
results after the task is completed is done by saving them into an index
named `.tasks`." A more modern way of doing this would be to save the
tasks into the index "under the hood" and to have APIs to manage the
saved tasks. This is the first step down that road: it drops the
requirement to have permissions to interact with the `.tasks` index when
fetching task statuses and when persisting statuses beyond the lifetime
of the task.

In particular, this moves the concept of the "origin" of an action into
a more prominent place in the Elasticsearch server. The origin of an
action is ignored by the server, but the security plugin uses the origin
to make requests on behalf of a user in such a way that the user need
not have permissions to perform these actions. It *can* be made to be
fairly precise. More specifically, we can create an internal user just
for the tasks API that just has permission to interact with the `.tasks`
index. This change doesn't do that, instead, it uses the ubiquitus
"xpack" user which has most permissions because it is simpler. Adding
the tasks user is something I'd like to get to in a follow up change.

Instead, the majority of this change is about moving the "origin"
concept from the security portion of x-pack into the server. This should
allow any code to use the origin. To keep the change managable I've also
opted to deprecate rather than remove the "origin" helpers in the
security code. Removing them is almost entirely mechanical and I'd like
to that in a follow up as well.

Relates to #35573
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@nik9000 nik9000 nik9000 approved these changes

@s1monw s1monw s1monw approved these changes

@bizybot bizybot Awaiting requested review from bizybot

@jaymode jaymode Awaiting requested review from jaymode

Assignees
No one assigned
Labels
>enhancement :Security/Authorization Roles, Privileges, DLS/FLS, RBAC/ABAC v6.5.1 v6.6.0 v7.0.0-beta1
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
9 participants
@tvernum @elasticmachine @tylersmalley @s1monw @ulab @epixa @nik9000 @colings86 @jaymode