Page MenuHomePhabricator

Kibana next sending telemetry to elastic.co
Closed, ResolvedPublic

Description

See the picture, kibana next sending telemetry to elastic.co

We are handling sensitive privacy things at kibana.
I guess better to we should disable that.

Solution

Event Timeline

Rxy renamed this task from Kibana ng sending telemetry to elastic.io to Kibana next sending telemetry to elastic.io.Aug 6 2020, 12:22 PM
Rxy renamed this task from Kibana next sending telemetry to elastic.io to Kibana next sending telemetry to elastic.co.
Rxy updated the task description. (Show Details)
Rxy updated the task description. (Show Details)

perhaps rOPUP[/modules/kibana/manifests/init.pp$39-47](https://phabricator.wikimedia.org/source/operations-puppet/browse/production/modules/kibana/manifests/init.pp$39-48) ?

'telemetry.enabled       => false, #T259794
'newsfeed.enabled'       => false, #T259794

not sure

Indeed, we should disable telemetry for kibana-next, I'll followup with a patch

Change 618948 had a related patch set uploaded (by Filippo Giunchedi; owner: Filippo Giunchedi):
[operations/puppet@production] kibana: disable telemetry and newsfeed

https://gerrit.wikimedia.org/r/618948

akosiaris triaged this task as Medium priority.Aug 7 2020, 9:36 AM

Change 618948 merged by Filippo Giunchedi:
[operations/puppet@production] kibana: disable telemetry and newsfeed

https://gerrit.wikimedia.org/r/618948

fgiunchedi claimed this task.

@Rxy telemetry is disabled now and indeed I can't see the requests anymore, please confirm and reopen if needed, thank you!

Can we set a hard CSP on this domain at the web server level so that in general our report will be "oh no, there's a request attempt we didn't notice" (possibly with a "hm.. and feature X is partly not working as a result") - as opposed to "oh no, we're actually making requests we don't want."

Can we set a hard CSP on this domain at the web server level so that in general our report will be "oh no, there's a request attempt we didn't notice" (possibly with a "hm.. and feature X is partly not working as a result") - as opposed to "oh no, we're actually making requests we don't want."

+1 to this!

It's probably beyond the scope of this task, but I see the benefit of evaluating more restrictive CSPs for externally-facing tools.

Can we set a hard CSP on this domain at the web server level so that in general our report will be "oh no, there's a request attempt we didn't notice" (possibly with a "hm.. and feature X is partly not working as a result") - as opposed to "oh no, we're actually making requests we don't want."

+1 to this!

It's probably beyond the scope of this task, but I see the benefit of evaluating more restrictive CSPs for externally-facing tools.

Agreed, likely worth having a standard CSP policy for tools that are supposed to be self contained (in another task)