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

Set default credentials for Kibana #4867

Merged
merged 1 commit into from Aug 14, 2017

Conversation

Projects
None yet
3 participants
@monicasarbu
Contributor

monicasarbu commented Aug 10, 2017

When loading the dashboards from Beats 6.0, the user needs to configure:

  • Elasticsearch URL
  • Kibana URL
  • Elasticsearch credentials
  • Kibana credentials

In Cloud, the credentials for connecting to Elasticsearch are the same as for connecting to Kibana, so the last step can be removed if we take (by default) the Kibana credentials from the Elasticsearch credentials.

This PR gets by default the credentials for Kibana from Elasticsearch configuration.

- Set by the default the credentials for connecting to Kibana the sam…
…e as for Elasticsearch

- Raise an error in case there are no dashboards to be imported

@tsg tsg merged commit fb3a7a3 into elastic:master Aug 14, 2017

6 checks passed

CLA Commit author is a member of Elasticsearch
Details
beats-ci Build finished.
Details
codecov/patch 38.09% of diff hit (within 100% threshold of 62.39%)
Details
codecov/project 62.31% (-0.08%) compared to e8f55ba
Details
continuous-integration/appveyor/pr AppVeyor build succeeded
Details
continuous-integration/travis-ci/pr The Travis CI build passed
Details

monicasarbu added a commit to monicasarbu/beats that referenced this pull request Aug 14, 2017

- Set by the default the credentials for connecting to Kibana the sam…
…e as for Elasticsearch (elastic#4867)

- Raise an error in case there are no dashboards to be imported
(cherry picked from commit fb3a7a3)

tsg added a commit that referenced this pull request Aug 14, 2017

- Set by the default the credentials for connecting to Kibana the sam…
…e as for Elasticsearch (#4867) (#4892)

- Raise an error in case there are no dashboards to be imported
(cherry picked from commit fb3a7a3)

@dedemorton dedemorton referenced this pull request Aug 15, 2017

Closed

Beats doc updates in 6.0 #4540

42 of 42 tasks complete
@LeeDr

This comment has been minimized.

Show comment
Hide comment
@LeeDr

LeeDr Aug 15, 2017

I'm -1 on this change. If you're using the same credentials (in Cloud or elsewhere) to connect to Elasticsearch and Kibana I'm guessing you're using the elastic superuser? I don't think this should be suggested or the default. You should generally use users with the minimal privileges they need to get the job done. Even in Cloud, we should create roles and users with the correct privileges for the task.

In my integration test I create a specific role and user beats_internal that has just the privileges needed for any of the beats to write their data to Elasticsearch (output.elasticsearch:).

And to access the Kibana API (setup.kibana:) to create the index-patterns, dashboards, etc I'm currently using the kibana user (kibana_system role). But I think even that is more privileged than it needs to be. Now I'm thinking the kibana_user role should be enough since any kibana_user can create all those things.

LeeDr commented Aug 15, 2017

I'm -1 on this change. If you're using the same credentials (in Cloud or elsewhere) to connect to Elasticsearch and Kibana I'm guessing you're using the elastic superuser? I don't think this should be suggested or the default. You should generally use users with the minimal privileges they need to get the job done. Even in Cloud, we should create roles and users with the correct privileges for the task.

In my integration test I create a specific role and user beats_internal that has just the privileges needed for any of the beats to write their data to Elasticsearch (output.elasticsearch:).

And to access the Kibana API (setup.kibana:) to create the index-patterns, dashboards, etc I'm currently using the kibana user (kibana_system role). But I think even that is more privileged than it needs to be. Now I'm thinking the kibana_user role should be enough since any kibana_user can create all those things.

@monicasarbu

This comment has been minimized.

Show comment
Hide comment
@monicasarbu

monicasarbu Aug 15, 2017

Contributor

I agree that having different users for ES and Kibana is what we should recommend for production, but this simplifies the getting started with xpack security and Cloud cases. It's a tradeoff, but in this case, I think adding convenience for getting started is worth it.

Note that the old implementation (writing directly in .kibana index) was worse in the sense that one couldn't have different users. So this is not a security regression since 5.x, on the contrary.

Contributor

monicasarbu commented Aug 15, 2017

I agree that having different users for ES and Kibana is what we should recommend for production, but this simplifies the getting started with xpack security and Cloud cases. It's a tradeoff, but in this case, I think adding convenience for getting started is worth it.

Note that the old implementation (writing directly in .kibana index) was worse in the sense that one couldn't have different users. So this is not a security regression since 5.x, on the contrary.

ramon-garcia added a commit to ramon-garcia/beats that referenced this pull request Dec 5, 2017

- Set by the default the credentials for connecting to Kibana the sam…
…e as for Elasticsearch (elastic#4867)

- Raise an error in case there are no dashboards to be imported

athom added a commit to athom/beats that referenced this pull request Jan 25, 2018

- Set by the default the credentials for connecting to Kibana the sam…
…e as for Elasticsearch (elastic#4867)

- Raise an error in case there are no dashboards to be imported
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment