search

elastic / kibana

Your window into the Elastic Stack
https://www.elastic.co/products/kibana
Other
19.82k stars 8.2k forks source link

Safeguard to prevent application privileges from being overwritten by incompatible Kibana versions #50424

Open ppf2 opened 4 years ago

ppf2 commented 4 years ago

@kobelb is familiar with the origin of this request :)

On Kibana's start-up, it fully recreates its application privileges using the Elasticsearch put privileges API with the definition of its privileges and what actions these privileges have access to, e.g.,

image

While we currently have a safeguard in place to prevent an older version (e.g., 6.8) of Kibana from starting up:

{"type":"log","@timestamp":"2019-11-11T19:57:04Z","tags":["status","plugin:spaces@6.8.1","error"],"pid":2941,"state":"red","message":"Status changed from yellow to red - Index .kibana_1 belongs to a version of Kibana that cannot be automatically migrated. Reset it or use the X-Pack upgrade assistant.","prevState":"yellow","prevMsg":"Waiting for Elasticsearch"}
{"type":"log","@timestamp":"2019-11-11T19:57:04Z","tags":["fatal","root"],"pid":2941,"message":"{ Error: Index .kibana_1 belongs to a version of Kibana that cannot be automatically migrated. Reset it or use the X-Pack upgrade assistant.\n    at assertIsSupportedIndex (/usr/share/kibana/src/server/saved_objects/migrations/core/elastic_index.js:246:15)\n    at Object.fetchInfo (/usr/share/kibana/src/server/saved_objects/migrations/core/elastic_index.js:52:12)\n  isBoom: true,\n  isServer: true,\n  data: null,\n  output:\n   { statusCode: 500,\n     payload:\n      { statusCode: 500,\n        error: 'Internal Server Error',\n        message: 'An internal server error occurred' },\n     headers: {} },\n  reformat: [Function],\n  [Symbol(SavedObjectsClientErrorCode)]: 'SavedObjectsClient/generalError' }"}
{"type":"log","@timestamp":"2019-11-11T19:57:04Z","tags":["fatal","root"],"pid":2941,"message":"{ Error: EACCES: permission denied, unlink '/var/run/kibana/kibana.pid'\n    at unlinkSync (fs.js:952:3)\n    at process.<anonymous> (/usr/share/kibana/src/server/pid/index.js:74:26)\n    at process.<anonymous> (/usr/share/kibana/node_modules/lodash/index.js:7407:25)\n    at Object.onceWrapper (events.js:277:13)\n    at process.emit (events.js:194:15)\n    at process.exit (internal/process/per_thread.js:168:15)\n    at Root.onRootShutdown [as onShutdown] (/usr/share/kibana/src/core/server/bootstrap.js:74:13)\n    at Root.shutdown (/usr/share/kibana/src/core/server/root/index.js:64:18)\n    at process._tickCallback (internal/process/next_tick.js:68:7)\n  errno: -13,\n  syscall: 'unlink',\n  code: 'EACCES',\n  path: '/var/run/kibana/kibana.pid' }"}

By the way, can we clarify the "Index .kibana_1 belongs to a version of Kibana that cannot be automatically migrated" message above to explicitly call out that the .kibana index has already been migrated to be used with a later version (<specify version>) of Kibana, and therefore, this instance of Kibana (<specify version>) cannot be started?

However, even though there is a safeguard in place above, we have seen a situation where the attempt to start up a 6.8 Kibana instance (pointed to a .kibana index that was previously migrated to 7.3) still allowed Kibana to overwrite its application privilege. In other words, starting up Kibana 6.8 ended up overwriting the application privileges previously created by another Kibana instance on 7.3 because Kibana 6.8 is the instance that was started up "later". Because the 6.8 privileges are not compatible with Kibana 7.3, users then encountered authorization issues.

This is a request to provide a safeguard to prevent a Kibana instance that has incompatible application privileges from overwriting Kibana's application privileges that were previously added as part of a successful Kibana upgrade.

kobelb commented 4 years ago

However, even though there is a safeguard in place above, we have seen a situation where the attempt to start up a 6.8 Kibana instance (pointed to a .kibana index that was previously migrated to 7.3) still allowed Kibana to overwrite its application privilege. In other words, starting up Kibana 6.8 ended up overwriting the application privileges previously created by another Kibana instance on 7.3 because Kibana 6.8 is the instance that was started up "later". Because the 6.8 privileges are not compatible with Kibana 7.3, users then encountered authorization issues.

We intentional support situations where an upgrade failed and the user downgraded to an older version of Kibana.

All of this is subject to change as we discuss how we want to support rolling upgrades, but the current design is intentional.

elasticmachine commented 4 years ago

Pinging @elastic/kibana-security (Team:Security)