Skip to content
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.

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

[Fleet] Added logs-elastic_agent* read privileges to kibana_system #91701

Merged
merged 6 commits into from
Nov 23, 2022
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
5 changes: 5 additions & 0 deletions docs/changelog/91701.yaml
Original file line number Diff line number Diff line change
@@ -0,0 +1,5 @@
pr: 91701
summary: "[Fleet] Added logs-elastic_agent* read privileges to `kibana_system`"
area: Authorization
type: enhancement
issues: []
Original file line number Diff line number Diff line change
Expand Up @@ -719,6 +719,8 @@ public static RoleDescriptor kibanaSystemRoleDescriptor(String name) {
// Fleet Server indices. Kibana create this indice before Fleet Server use them.
// Fleet Server indices. Kibana read and write to this indice to manage Elastic Agents
RoleDescriptor.IndicesPrivileges.builder().indices(".fleet*").allowRestrictedIndices(true).privileges("all").build(),
// Fleet telemetry queries Agent Logs indices in kibana task runner
RoleDescriptor.IndicesPrivileges.builder().indices("logs-elastic_agent*").privileges("read").build(),
Copy link
Member

Choose a reason for hiding this comment

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

question: I see @joshdover hasn't replied on this yet in https://github.com/elastic/ingest-dev/issues/1261#issuecomment-1322223139, did you folks sync over Slack/Zoom? I just want to be sure we're all aligned, if so - the change looks good from the Kibana Security perspective.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Not yet, I'll wait for his feedback.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Copy link
Member

Choose a reason for hiding this comment

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

Great, thanks for confirming

Copy link
Contributor Author

@juliaElastic juliaElastic Nov 23, 2022

Choose a reason for hiding this comment

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

Is there anything else you need from me to approve?

Copy link
Member

Choose a reason for hiding this comment

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

Nope, everything looks good from Kibana perspective, feel free to merge as soon as ES team approves the change.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@elastic/elasticsearch-team Hey, could someone review and approve?

Copy link
Contributor

@slobodanadamovic slobodanadamovic Nov 23, 2022

Choose a reason for hiding this comment

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

@juliaElastic
We try to advise people not to use @elastic/elasticsearch-team handle, since it pings the whole Elasticsearch team (116 people).

I see that you already notified the correct area team (Team:Security) and that Yang (who is on PTO) did the initial review. Everyone from Security team receives notifications for every comment, so you can either simply comment on this PR or ping @elastic/es-security if there is an urgent need for someone to have a look.

From my perspective, the changes look good! 🚀 If you need this to be backported to 8.6 branch you can simply apply the auto-backport-and-merge label (before merging this PR) and it will automatically open a new PR and merge it (otherwise you would have to do it manually).

Another small suggestion would be to update the description of this PR (as it serves for future references) and remove contributor template bullet points and the link to a private GitHub repo.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Thank you for your suggestions! I wasn't sure which team to ping, as there was no team assigned as pr reviewer. I'll keep this in mind.

Copy link
Contributor

Choose a reason for hiding this comment

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

I've made the same mistakes myself. It's not something you could have known, so no worries. :)

// Legacy "Alerts as data" used in Security Solution.
// Kibana user creates these indices; reads / writes to them.
RoleDescriptor.IndicesPrivileges.builder().indices(ReservedRolesStore.ALERTS_LEGACY_INDEX).privileges("all").build(),
Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -732,6 +732,19 @@ public void testKibanaSystemRole() {
".fleet-servers"
).forEach(index -> assertAllIndicesAccessAllowed(kibanaRole, index));

// read-only indices for Fleet telemetry
Arrays.asList("logs-elastic_agent-default", "logs-elastic_agent.fleet_server-default").forEach((index) -> {
assertThat(kibanaRole.indices().allowedIndicesMatcher("indices:foo").test(mockIndexAbstraction(index)), is(false));
assertThat(kibanaRole.indices().allowedIndicesMatcher("indices:bar").test(mockIndexAbstraction(index)), is(false));
assertThat(kibanaRole.indices().allowedIndicesMatcher(GetIndexAction.NAME).test(mockIndexAbstraction(index)), is(true));
assertThat(kibanaRole.indices().allowedIndicesMatcher(CreateIndexAction.NAME).test(mockIndexAbstraction(index)), is(false));
assertThat(kibanaRole.indices().allowedIndicesMatcher(IndexAction.NAME).test(mockIndexAbstraction(index)), is(false));
assertThat(kibanaRole.indices().allowedIndicesMatcher(DeleteAction.NAME).test(mockIndexAbstraction(index)), is(false));
assertThat(kibanaRole.indices().allowedIndicesMatcher(SearchAction.NAME).test(mockIndexAbstraction(index)), is(true));
assertThat(kibanaRole.indices().allowedIndicesMatcher(MultiSearchAction.NAME).test(mockIndexAbstraction(index)), is(true));
assertThat(kibanaRole.indices().allowedIndicesMatcher(GetAction.NAME).test(mockIndexAbstraction(index)), is(true));
});

// read-only index for Endpoint and Osquery manager specific action responses
Arrays.asList(".logs-endpoint.action.responses-" + randomAlphaOfLength(randomIntBetween(0, 13))).forEach((index) -> {
final IndexAbstraction indexAbstraction = mockIndexAbstraction(index);
Expand Down