[HTTP] First pass of making Kibana work with internal restrictions enforced#162258
[HTTP] First pass of making Kibana work with internal restrictions enforced#162258jloleysens merged 17 commits intoelastic:mainfrom
Conversation
TinaHeiligers
left a comment
There was a problem hiding this comment.
We'll need to extend our testing around protecting internal APIs. An overall test asserting against the ones that are public would be a start. I'm thinking along the lines of the test we have for keeping track of which saved objects have migrations, but not necessarily a hash map.
We can build on it as we make more changes.
packages/core/status/core-status-server-internal/src/routes/status_preboot.ts
Outdated
Show resolved
Hide resolved
packages/core/status/core-status-server-internal/src/status_service.test.ts
Show resolved
Hide resolved
|
Pinging @elastic/kibana-core (Team:Core) |
|
Pinging @elastic/fleet (Team:Fleet) |
💛 Build succeeded, but was flaky
Failed CI StepsTest Failures
Metrics [docs]Module Count
Async chunks
History
To update your PR or re-run it, just comment with: |
TinaHeiligers
left a comment
There was a problem hiding this comment.
I'm worried about the flaky cypress test. The tests are super hard to debug for non-domain owners. @elastic/appex-sharedux is there something we can do to make cypress testing easier and easier to debug?
PR code changes to fine and running it locally works!
LGTM
| }), | ||
| }, | ||
| options: { | ||
| access: 'public', |
There was a problem hiding this comment.
A lot of Core routes that were (rightfully) switched to public aren't listed in the issue's description (e.g this one). Future us would probably be very grateful if we had an exhaustive list somewhere for when we may want to switch some of them back to internal (e.g when updating the internal consumers to provide the header)
| headers.append('kbn-xsrf', 'kibana'); | ||
| headers.append(X_ELASTIC_INTERNAL_ORIGIN_REQUEST, 'kibana'); |
There was a problem hiding this comment.
🙈 I don't even want to know why the home plugin isn't using core's fetch service here...
xcrzx
left a comment
There was a problem hiding this comment.
Hey @jloleysens, I've checked some other internal endpoints that are being used externally. Here's a list of endpoints called by the diagnostic tool (used by our support team): https://github.com/elastic/support-diagnostics/blob/34a6670959e03b81301abf941f5fe6e4ff11c736/src/main/resources/kibana-rest.yml.
This list includes:
- /internal/detection_engine/prebuilt_rules/status
- /internal/security/me
I believe we should add access: 'public' to these endpoints as well. Also, other Security Solution teams might be using different internal endpoints for external tools so broader communication about the new restriction would be much appreciated.
…forced (elastic#162258) ## Summary When turning on `server.restrictInternalApis` a number of issues surfaced due to defaulting to internal resulting in `400`s for: * HTTP resources * Static assets via `registerStaticDir` * Use of `res.render(Html|Js|Css)` outside of HTTP resources This PR: * defaults our HTTP resources service to register routes by default `public`, same for static dirs. * Did an audit of all renderX usages, if outside of HTTP resources I added an explicit `access: public` * ...what else? ### Set `access: 'public'` for known set of "system" routes Method | Path | Comment -- | -- | -- GET | /api/status GET | /api/stats GET | /translations/{locale}.json GET | /api/fleet/agent_policies GET | /api/task_manager/_background_task_utilization GET | /internal/task_manager/_background_task_utilization GET | /internal/detection_engine/health/_cluster POST | /internal/detection_engine/health/_cluster GET | /internal/detection_engine/health/_space POST | /internal/detection_engine/health/_space POST | /internal/detection_engine/health/_rule POST | /internal/detection_engine/health/_setup GET | /bootstrap.js GET | /bootstrap-anonymous.js GET | \*\*/bundles/\* | Core's routes for serving JS & CSS bundles ## How to test Run this PR with `kibana.dev.yml` containing `server.restrictInternalApis: true` and navigate around Kibana UI checking that there are no `400`s in the network resources tab due to access restrictions. ## Notes * Either left a comment about why `access` was set public or a simple unit test to check that we are setting access for a given route ## To do - [x] Manually test Kibana - [x] Manually test with `interactiveSetup` plugin - [ ] Add integration and e2e test (will do in a follow up PR) Related: elastic#162149 --------- Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Summary
When turning on
server.restrictInternalApisa number of issues surfaced due to defaulting to internal resulting in400s for:registerStaticDirres.render(Html|Js|Css)outside of HTTP resourcesThis PR:
public, same for static dirs.access: publicSet
access: 'public'for known set of "system" routesHow to test
Run this PR with
kibana.dev.ymlcontainingserver.restrictInternalApis: trueand navigate around Kibana UI checking that there are no400s in the network resources tab due to access restrictions.Notes
accesswas set public or a simple unit test to check that we are setting access for a given routeTo do
interactiveSetuppluginRelated: #162149