-
Notifications
You must be signed in to change notification settings - Fork 8.3k
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
[HTTP] First pass of making Kibana work with internal restrictions enforced #162258
[HTTP] First pass of making Kibana work with internal restrictions enforced #162258
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
💛 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: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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
@@ -28,6 +28,7 @@ export const registerTranslationsRoute = (router: IRouter, locale: string) => { | |||
}), | |||
}, | |||
options: { | |||
access: 'public', |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🙈 I don't even want to know why the home plugin isn't using core's fetch service here...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
response ops changes LGTM
…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 <[email protected]>
Summary
When turning on
server.restrictInternalApis
a number of issues surfaced due to defaulting to internal resulting in400
s for:registerStaticDir
res.render(Html|Js|Css)
outside of HTTP resourcesThis PR:
public
, same for static dirs.access: public
Set
access: 'public'
for known set of "system" routesHow to test
Run this PR with
kibana.dev.yml
containingserver.restrictInternalApis: true
and navigate around Kibana UI checking that there are no400
s in the network resources tab due to access restrictions.Notes
access
was set public or a simple unit test to check that we are setting access for a given routeTo do
interactiveSetup
pluginRelated: #162149