Turn on internal API restriction for serverless tests#162636
Turn on internal API restriction for serverless tests#162636jloleysens merged 9 commits intoelastic:mainfrom
Conversation
jloleysens
added
Feature:http
Team:Core
|
Pinging @elastic/kibana-core (Team:Core) |
|
@jloleysens We just merged a fix for the security request headers tests. When you resolve conflicts you should be able to just use what's in main. |
|
Pinging @elastic/apm-ui (Team:APM) |
| }, | ||
| sourceArgs: ['--no-base-path', '--env.name=development'], | ||
| serverArgs: [ | ||
| `--server.restrictInternalApis=true`, |
There was a problem hiding this comment.
The most important change of the PR
💚 Build Succeeded
Metrics [docs]
History
To update your PR or re-run it, just comment with: |
TinaHeiligers
left a comment
TinaHeiligers
left a comment
There was a problem hiding this comment.
Most Fleet API's are intended to be public but the work is still pending. As it is right now, they're internal.
Ideally, we need Fleet's approval before going ahead with this rather than assuming they are.
| const { body, status } = await supertest | ||
| .post('/api/fleet/fleet_server_hosts') | ||
| .set(svlCommonApi.getCommonRequestHeader()) | ||
| .set(svlCommonApi.getInternalRequestHeader()) |
There was a problem hiding this comment.
the API's public, not internal. Fleet has an open issue to change to 'public' again: https://github.com/elastic/ingest-dev/issues/1921
There was a problem hiding this comment.
This means until the linked issue is resolved, this API would be treated as internal ?
| const { body, status } = await supertest | ||
| .post('/api/fleet/proxies') | ||
| .set(svlCommonApi.getCommonRequestHeader()) | ||
| .set(svlCommonApi.getInternalRequestHeader()) |
| const { body } = await supertest | ||
| .post(`/api/alerting/rule`) | ||
| .set('kbn-xsrf', 'foo') | ||
| .set('x-elastic-internal-origin', 'foo') |
There was a problem hiding this comment.
👍 . confirmed with @elastic/actionable-observability, their APIs are 'internal'
| const response = await supertest | ||
| .get(`/api/alerting/rule/${id}`) | ||
| .set('kbn-xsrf', 'foo') | ||
| .set('x-elastic-internal-origin', 'foo'); |
| const { body } = await supertest | ||
| .post(`/api/content_management/rpc/create`) | ||
| .set('kbn-xsrf', 'foo') | ||
| .set('x-elastic-internal-origin', 'foo') |
| await supertest | ||
| .delete(`/api/alerting/rule/${ruleId}`) | ||
| .set('kbn-xsrf', 'foo') | ||
| .set('x-elastic-internal-origin', 'foo'); |
| await supertest | ||
| .delete(`/api/actions/connector/${actionId}`) | ||
| .set('kbn-xsrf', 'foo') | ||
| .set('x-elastic-internal-origin', 'foo'); |
dmlemeshko
left a comment
dmlemeshko
left a comment
There was a problem hiding this comment.
LGTM Code review only
achyutjhunjhunwala
left a comment
achyutjhunjhunwala
left a comment
There was a problem hiding this comment.
APM changes are good to go, only concern is with the Fleet API which @TinaHeiligers has already highlighted
## Summary Since we already have some E2E tests running for serverless, this PR turns on the internal API restriction flag to test whether our UI functions _as such_ under these tests. An alternative could be to have a specific smoke test for this, but it seems this is thoroughly covered by piggy-backing off the existing set of tests. Blocks: elastic#162149
11 participants
Summary
Since we already have some E2E tests running for serverless, this PR turns on the internal API restriction flag to test whether our UI functions as such under these tests.
An alternative could be to have a specific smoke test for this, but it seems this is thoroughly covered by piggy-backing off the existing set of tests.
Blocks: #162149