[8.19] [Security Solution] Enforce sending the request to API even if offline, for air-gapped environment. (#220510)#223204
Merged
kibanamachine merged 1 commit intoelastic:8.19from Jun 10, 2025
Conversation
…e, for air-gapped environment. (elastic#220510) **Resolves: elastic#181808** ## Summary I am fixing the issue of the Rules and Alerts tabs in Security, as well as the Fleet tab in Management, that gets stalled in air-gapped environment. I am doing so by enforcing the request to be sent to the API even when offline. ### Historical context: During investigation of the original issue elastic#181808 I proved that Kibana doesn't try to reach to EPR in the air-gapped environment (that is, with the `xpack.fleet.isAirGapped: true` flag, and WIFI being turned ON). I commented this [here](elastic#181808 (comment)) and we closed the issue. However, @111andre111 reached out to us saying that this wasn't enough, as the real issue remains, that is, Kibana doesn't behave properly when: - `xpack.fleet.isAirGapped` flag is set to `true` - there is no Internet connection (WIFI off or cable physically disconnected) That's why we reopened the ticket and I restarted the investigation. My first observation was that when I turn off the WIFI, I cannot see requests to the API being sent in the Network tab in Dev Tools, most importantly to the `_bootstrap` endpoint at the first entrance to the Solution app, and other endpoints later. I searched that the browser discovers being offline and suppresses such calls. When WIFI is back ON, then the browser sends these requests. That was exactly what I saw in the Network tab. I searched and found an option to force browser to always send the request, regardless of what it thinks about connectivity. Such option, `networkMode: 'always'`, can be added to TanStackQuery client. I started working on adding this option to occurences of `useQuery` and `useMutation`, and immediately sounded success, as the behavior was correct. However, @xcrzx rigthfully pointed out, that it would be much better to only add it to one place, that is the configuration of the QueryClient. I did it, and to my surprise, the problem returned. I noticed that adding this option to the QueryClient in Fleet solved the problem in the Fleet tab immediately, but adding this option to the `SecuritySolutionQueryClient` does nothing, like it was completely ignored. I searched different options and spent two more days debugging the problem, but then, when paired up again with Dmitrii, he found that the `SecuritySolutionQueryClient` is overshadowed by some other QueryClient present in the stack of components much below, the `CasesContext`. That discovery enabled me to add this new setting to the other QueryClient, and this fixes the issue. However, we think that it will be worth investigating why we need this second context, as the situation when one QueryClient overshadows another one, smells badly and may be a source of other issues as well (I will reach out to the team responsible for the CasesContext and ask if we can unify this somehow). ## BEFORE https://github.com/user-attachments/assets/662dab73-b1bd-4d6b-9d15-c35efab679c6 ## AFTER https://github.com/user-attachments/assets/b905bde0-150d-478d-9734-9003fb5bcf66 ### Checklist Check the PR satisfies following conditions. Reviewers should verify this PR satisfies this list as well. - [ ] [Unit or functional tests](https://www.elastic.co/guide/en/kibana/master/development-tests.html) were updated or added to match the most common scenarios - [ ] If a plugin configuration key changed, check if it needs to be allowlisted in the cloud and added to the [docker list](https://github.com/elastic/kibana/blob/main/src/dev/build/tasks/os_packages/docker_generator/resources/base/bin/kibana-docker) - [ ] This was checked for breaking HTTP API changes, and any breaking changes have been approved by the breaking-change committee. The `release_note:breaking` label should be applied in these situations. - [ ] [Flaky Test Runner](https://ci-stats.kibana.dev/trigger_flaky_test_runner/1) was used on any tests changed - [ ] The PR description includes the appropriate Release Notes section, and the correct `release_note:*` label is applied per the [guidelines](https://www.elastic.co/guide/en/kibana/master/contributing.html#kibana-release-notes-process) --------- Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com> (cherry picked from commit 7ad35a4)
botelastic
bot
added
the
Team:Fleet
Contributor
|
Pinging @elastic/fleet (Team:Fleet) |
![github-actions[bot]](https://avatars.githubusercontent.com/in/15368?s=60&v=4){kind=small}
5 tasks
Contributor
💛 Build succeeded, but was flaky
Failed CI StepsTest Failures
Metrics [docs]Async chunks
Page load bundle
cc @jkelas |
jkelas
pushed a commit
that referenced
this pull request
Jun 25, 2025
… offline, for air-gapped environment. (#220510) (#225102) # Backport This will backport the following commits from `main` to `8.18`: - [[Security Solution] Enforce sending the request to API even if offline, for air-gapped environment. (#220510)](#220510) <!--- Backport version: 10.0.0 --> ### Questions ? Please refer to the [Backport tool documentation](https://github.com/sorenlouv/backport) <!--BACKPORT [{"author":{"name":"Jacek Kolezynski","email":"jacek.kolezynski@elastic.co"},"sourceCommit":{"committedDate":"2025-06-10T10:14:45Z","message":"[Security Solution] Enforce sending the request to API even if offline, for air-gapped environment. (#220510)\n\n**Resolves: #181808**\n\n## Summary\n\nI am fixing the issue of the Rules and Alerts tabs in Security, as well\nas the Fleet tab in Management, that gets stalled in air-gapped\nenvironment. I am doing so by enforcing the request to be sent to the\nAPI even when offline.\n\n### Historical context:\nDuring investigation of the original issue #181808 I proved that Kibana\ndoesn't try to reach to EPR in the air-gapped environment (that is, with\nthe `xpack.fleet.isAirGapped: true` flag, and WIFI being turned ON). I\ncommented this\n[here](https://github.com/elastic/kibana/issues/181808#issuecomment-2829911511)\nand we closed the issue. However, @111andre111 reached out to us saying\nthat this wasn't enough, as the real issue remains, that is, Kibana\ndoesn't behave properly when:\n- `xpack.fleet.isAirGapped` flag is set to `true`\n- there is no Internet connection (WIFI off or cable physically\ndisconnected)\n\nThat's why we reopened the ticket and I restarted the investigation. \nMy first observation was that when I turn off the WIFI, I cannot see\nrequests to the API being sent in the Network tab in Dev Tools, most\nimportantly to the `_bootstrap` endpoint at the first entrance to the\nSolution app, and other endpoints later. I searched that the browser\ndiscovers being offline and suppresses such calls. When WIFI is back ON,\nthen the browser sends these requests. That was exactly what I saw in\nthe Network tab.\nI searched and found an option to force browser to always send the\nrequest, regardless of what it thinks about connectivity. Such option,\n`networkMode: 'always'`, can be added to TanStackQuery client.\n\nI started working on adding this option to occurences of `useQuery` and\n`useMutation`, and immediately sounded success, as the behavior was\ncorrect. However, @xcrzx rigthfully pointed out, that it would be much\nbetter to only add it to one place, that is the configuration of the\nQueryClient. I did it, and to my surprise, the problem returned.\nI noticed that adding this option to the QueryClient in Fleet solved the\nproblem in the Fleet tab immediately, but adding this option to the\n`SecuritySolutionQueryClient` does nothing, like it was completely\nignored.\nI searched different options and spent two more days debugging the\nproblem, but then, when paired up again with Dmitrii, he found that the\n`SecuritySolutionQueryClient` is overshadowed by some other QueryClient\npresent in the stack of components much below, the `CasesContext`. That\ndiscovery enabled me to add this new setting to the other QueryClient,\nand this fixes the issue. However, we think that it will be worth\ninvestigating why we need this second context, as the situation when one\nQueryClient overshadows another one, smells badly and may be a source of\nother issues as well (I will reach out to the team responsible for the\nCasesContext and ask if we can unify this somehow).\n\n## BEFORE\n\n\nhttps://github.com/user-attachments/assets/662dab73-b1bd-4d6b-9d15-c35efab679c6\n\n## AFTER\n\n\nhttps://github.com/user-attachments/assets/b905bde0-150d-478d-9734-9003fb5bcf66\n\n\n\n### Checklist\n\nCheck the PR satisfies following conditions. \n\nReviewers should verify this PR satisfies this list as well.\n\n- [ ] [Unit or functional\ntests](https://www.elastic.co/guide/en/kibana/master/development-tests.html)\nwere updated or added to match the most common scenarios\n- [ ] If a plugin configuration key changed, check if it needs to be\nallowlisted in the cloud and added to the [docker\nlist](https://github.com/elastic/kibana/blob/main/src/dev/build/tasks/os_packages/docker_generator/resources/base/bin/kibana-docker)\n- [ ] This was checked for breaking HTTP API changes, and any breaking\nchanges have been approved by the breaking-change committee. The\n`release_note:breaking` label should be applied in these situations.\n- [ ] [Flaky Test\nRunner](https://ci-stats.kibana.dev/trigger_flaky_test_runner/1) was\nused on any tests changed\n- [ ] The PR description includes the appropriate Release Notes section,\nand the correct `release_note:*` label is applied per the\n[guidelines](https://www.elastic.co/guide/en/kibana/master/contributing.html#kibana-release-notes-process)\n\n---------\n\nCo-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>","sha":"7ad35a4a33c3bd4d4f4e33acff20f4ebaa3242ce","branchLabelMapping":{"^v9.1.0$":"main","^v(\\d+).(\\d+).\\d+$":"$1.$2"}},"sourcePullRequest":{"labels":["bug","release_note:fix","Team:Fleet","Team:Detections and Resp","Team: SecuritySolution","Team:Detection Rule Management","ci:build-all-platforms","ci:build-os-packages","Feature:Prebuilt Detection Rules","ci:build-cloud-image","backport:version","v9.1.0","v8.19.0","v9.0.3"],"title":"[Security Solution] Enforce sending the request to API even if offline, for air-gapped environment.","number":220510,"url":"https://github.com/elastic/kibana/pull/220510","mergeCommit":{"message":"[Security Solution] Enforce sending the request to API even if offline, for air-gapped environment. (#220510)\n\n**Resolves: #181808**\n\n## Summary\n\nI am fixing the issue of the Rules and Alerts tabs in Security, as well\nas the Fleet tab in Management, that gets stalled in air-gapped\nenvironment. I am doing so by enforcing the request to be sent to the\nAPI even when offline.\n\n### Historical context:\nDuring investigation of the original issue #181808 I proved that Kibana\ndoesn't try to reach to EPR in the air-gapped environment (that is, with\nthe `xpack.fleet.isAirGapped: true` flag, and WIFI being turned ON). I\ncommented this\n[here](https://github.com/elastic/kibana/issues/181808#issuecomment-2829911511)\nand we closed the issue. However, @111andre111 reached out to us saying\nthat this wasn't enough, as the real issue remains, that is, Kibana\ndoesn't behave properly when:\n- `xpack.fleet.isAirGapped` flag is set to `true`\n- there is no Internet connection (WIFI off or cable physically\ndisconnected)\n\nThat's why we reopened the ticket and I restarted the investigation. \nMy first observation was that when I turn off the WIFI, I cannot see\nrequests to the API being sent in the Network tab in Dev Tools, most\nimportantly to the `_bootstrap` endpoint at the first entrance to the\nSolution app, and other endpoints later. I searched that the browser\ndiscovers being offline and suppresses such calls. When WIFI is back ON,\nthen the browser sends these requests. That was exactly what I saw in\nthe Network tab.\nI searched and found an option to force browser to always send the\nrequest, regardless of what it thinks about connectivity. Such option,\n`networkMode: 'always'`, can be added to TanStackQuery client.\n\nI started working on adding this option to occurences of `useQuery` and\n`useMutation`, and immediately sounded success, as the behavior was\ncorrect. However, @xcrzx rigthfully pointed out, that it would be much\nbetter to only add it to one place, that is the configuration of the\nQueryClient. I did it, and to my surprise, the problem returned.\nI noticed that adding this option to the QueryClient in Fleet solved the\nproblem in the Fleet tab immediately, but adding this option to the\n`SecuritySolutionQueryClient` does nothing, like it was completely\nignored.\nI searched different options and spent two more days debugging the\nproblem, but then, when paired up again with Dmitrii, he found that the\n`SecuritySolutionQueryClient` is overshadowed by some other QueryClient\npresent in the stack of components much below, the `CasesContext`. That\ndiscovery enabled me to add this new setting to the other QueryClient,\nand this fixes the issue. However, we think that it will be worth\ninvestigating why we need this second context, as the situation when one\nQueryClient overshadows another one, smells badly and may be a source of\nother issues as well (I will reach out to the team responsible for the\nCasesContext and ask if we can unify this somehow).\n\n## BEFORE\n\n\nhttps://github.com/user-attachments/assets/662dab73-b1bd-4d6b-9d15-c35efab679c6\n\n## AFTER\n\n\nhttps://github.com/user-attachments/assets/b905bde0-150d-478d-9734-9003fb5bcf66\n\n\n\n### Checklist\n\nCheck the PR satisfies following conditions. \n\nReviewers should verify this PR satisfies this list as well.\n\n- [ ] [Unit or functional\ntests](https://www.elastic.co/guide/en/kibana/master/development-tests.html)\nwere updated or added to match the most common scenarios\n- [ ] If a plugin configuration key changed, check if it needs to be\nallowlisted in the cloud and added to the [docker\nlist](https://github.com/elastic/kibana/blob/main/src/dev/build/tasks/os_packages/docker_generator/resources/base/bin/kibana-docker)\n- [ ] This was checked for breaking HTTP API changes, and any breaking\nchanges have been approved by the breaking-change committee. The\n`release_note:breaking` label should be applied in these situations.\n- [ ] [Flaky Test\nRunner](https://ci-stats.kibana.dev/trigger_flaky_test_runner/1) was\nused on any tests changed\n- [ ] The PR description includes the appropriate Release Notes section,\nand the correct `release_note:*` label is applied per the\n[guidelines](https://www.elastic.co/guide/en/kibana/master/contributing.html#kibana-release-notes-process)\n\n---------\n\nCo-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>","sha":"7ad35a4a33c3bd4d4f4e33acff20f4ebaa3242ce"}},"sourceBranch":"main","suggestedTargetBranches":[],"targetPullRequestStates":[{"branch":"main","label":"v9.1.0","branchLabelMappingKey":"^v9.1.0$","isSourceBranch":true,"state":"MERGED","url":"https://github.com/elastic/kibana/pull/220510","number":220510,"mergeCommit":{"message":"[Security Solution] Enforce sending the request to API even if offline, for air-gapped environment. (#220510)\n\n**Resolves: #181808**\n\n## Summary\n\nI am fixing the issue of the Rules and Alerts tabs in Security, as well\nas the Fleet tab in Management, that gets stalled in air-gapped\nenvironment. I am doing so by enforcing the request to be sent to the\nAPI even when offline.\n\n### Historical context:\nDuring investigation of the original issue #181808 I proved that Kibana\ndoesn't try to reach to EPR in the air-gapped environment (that is, with\nthe `xpack.fleet.isAirGapped: true` flag, and WIFI being turned ON). I\ncommented this\n[here](https://github.com/elastic/kibana/issues/181808#issuecomment-2829911511)\nand we closed the issue. However, @111andre111 reached out to us saying\nthat this wasn't enough, as the real issue remains, that is, Kibana\ndoesn't behave properly when:\n- `xpack.fleet.isAirGapped` flag is set to `true`\n- there is no Internet connection (WIFI off or cable physically\ndisconnected)\n\nThat's why we reopened the ticket and I restarted the investigation. \nMy first observation was that when I turn off the WIFI, I cannot see\nrequests to the API being sent in the Network tab in Dev Tools, most\nimportantly to the `_bootstrap` endpoint at the first entrance to the\nSolution app, and other endpoints later. I searched that the browser\ndiscovers being offline and suppresses such calls. When WIFI is back ON,\nthen the browser sends these requests. That was exactly what I saw in\nthe Network tab.\nI searched and found an option to force browser to always send the\nrequest, regardless of what it thinks about connectivity. Such option,\n`networkMode: 'always'`, can be added to TanStackQuery client.\n\nI started working on adding this option to occurences of `useQuery` and\n`useMutation`, and immediately sounded success, as the behavior was\ncorrect. However, @xcrzx rigthfully pointed out, that it would be much\nbetter to only add it to one place, that is the configuration of the\nQueryClient. I did it, and to my surprise, the problem returned.\nI noticed that adding this option to the QueryClient in Fleet solved the\nproblem in the Fleet tab immediately, but adding this option to the\n`SecuritySolutionQueryClient` does nothing, like it was completely\nignored.\nI searched different options and spent two more days debugging the\nproblem, but then, when paired up again with Dmitrii, he found that the\n`SecuritySolutionQueryClient` is overshadowed by some other QueryClient\npresent in the stack of components much below, the `CasesContext`. That\ndiscovery enabled me to add this new setting to the other QueryClient,\nand this fixes the issue. However, we think that it will be worth\ninvestigating why we need this second context, as the situation when one\nQueryClient overshadows another one, smells badly and may be a source of\nother issues as well (I will reach out to the team responsible for the\nCasesContext and ask if we can unify this somehow).\n\n## BEFORE\n\n\nhttps://github.com/user-attachments/assets/662dab73-b1bd-4d6b-9d15-c35efab679c6\n\n## AFTER\n\n\nhttps://github.com/user-attachments/assets/b905bde0-150d-478d-9734-9003fb5bcf66\n\n\n\n### Checklist\n\nCheck the PR satisfies following conditions. \n\nReviewers should verify this PR satisfies this list as well.\n\n- [ ] [Unit or functional\ntests](https://www.elastic.co/guide/en/kibana/master/development-tests.html)\nwere updated or added to match the most common scenarios\n- [ ] If a plugin configuration key changed, check if it needs to be\nallowlisted in the cloud and added to the [docker\nlist](https://github.com/elastic/kibana/blob/main/src/dev/build/tasks/os_packages/docker_generator/resources/base/bin/kibana-docker)\n- [ ] This was checked for breaking HTTP API changes, and any breaking\nchanges have been approved by the breaking-change committee. The\n`release_note:breaking` label should be applied in these situations.\n- [ ] [Flaky Test\nRunner](https://ci-stats.kibana.dev/trigger_flaky_test_runner/1) was\nused on any tests changed\n- [ ] The PR description includes the appropriate Release Notes section,\nand the correct `release_note:*` label is applied per the\n[guidelines](https://www.elastic.co/guide/en/kibana/master/contributing.html#kibana-release-notes-process)\n\n---------\n\nCo-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>","sha":"7ad35a4a33c3bd4d4f4e33acff20f4ebaa3242ce"}},{"branch":"8.19","label":"v8.19.0","branchLabelMappingKey":"^v(\\d+).(\\d+).\\d+$","isSourceBranch":false,"url":"https://github.com/elastic/kibana/pull/223204","number":223204,"state":"MERGED","mergeCommit":{"sha":"dfad25f66d859c35095d09d5ab832746d1c9fba2","message":"[8.19] [Security Solution] Enforce sending the request to API even if offline, for air-gapped environment. (#220510) (#223204)\n\n# Backport\n\nThis will backport the following commits from `main` to `8.19`:\n- [[Security Solution] Enforce sending the request to API even if\noffline, for air-gapped environment.\n(#220510)](https://github.com/elastic/kibana/pull/220510)\n\n\n\n### Questions ?\nPlease refer to the [Backport tool\ndocumentation](https://github.com/sorenlouv/backport)\n\n\n\nCo-authored-by: Jacek Kolezynski <jacek.kolezynski@elastic.co>"}},{"branch":"9.0","label":"v9.0.3","branchLabelMappingKey":"^v(\\d+).(\\d+).\\d+$","isSourceBranch":false,"url":"https://github.com/elastic/kibana/pull/223205","number":223205,"state":"MERGED","mergeCommit":{"sha":"0af79efd1ddde344765e2c403e104517d31fe067","message":"[9.0] [Security Solution] Enforce sending the request to API even if offline, for air-gapped environment. (#220510) (#223205)\n\n# Backport\n\nThis will backport the following commits from `main` to `9.0`:\n- [[Security Solution] Enforce sending the request to API even if\noffline, for air-gapped environment.\n(#220510)](https://github.com/elastic/kibana/pull/220510)\n\n\n\n### Questions ?\nPlease refer to the [Backport tool\ndocumentation](https://github.com/sorenlouv/backport)\n\n\n\nCo-authored-by: Jacek Kolezynski <jacek.kolezynski@elastic.co>"}}]}] BACKPORT--> Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Backport
This will backport the following commits from
mainto8.19:Questions ?
Please refer to the Backport tool documentation