-
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
[Cloud Security] CSPM AWS agentless selector #171671
Conversation
ce9e2a1
to
b7327f8
Compare
Pinging @elastic/fleet (Team:Fleet) |
Currently, we don't support Cloud provider auto-deployment (CloudFormation, Google Cloud Shell, Azure ARM) on the same agent policy. As the example below, once we save multiple CSPM integrations on the same agent policy, including a CloudFormation integration, the Agent enrollment flyout only shows the "Launch CloudFormation" option and always points to the first CloudFormation installed. Recordings Saving manual CSPM AWS - ok Screen.Recording.2023-11-29.at.12.04.04.PM.movSaving a Cloudformation CSPM AWS - ok Screen.Recording.2023-11-29.at.12.03.01.PM.movSaving another manual CSPM AWS - it shows only cloud formation deployment Screen.Recording.2023-11-29.at.12.02.01.PM.movThen it only shows cloud formation deployment for all the CSPM AWS integrations Screen.Recording.2023-11-29.at.12.05.27.PM.mov@maxcold - From what I could see on the agent policy below, it looks like the agentless policy agent would recognize all the 2 manual cspm integrations and deploy them individually once the integration is saved. Then the user needs to deploy the CloudFormation integration manually in their own AWS account. If that's the case, I don't see benefits in providing agentless integrations with CloudFormation since it doesn't change anything from the agent-based, shouldn't we provide agentless integration for manual only? Screen.Recording.2023-11-29.at.12.30.21.PM.movAgent Policy:
|
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.
@opauloh thanks for the thorough review, my bad for not providing enough context. With agentless we only support the Manual > Direct Access Key or Temporary Access Key methods. As the feature is currently hidden via a feature flag, which is not enabled anywhere + agentless is enabled for only a handful of org ids from our team, my plan was to limit the installation option in the next PR to not bloat this one for easier review, I should've stated it in the description. Wdyt, is it acceptable to move forward with this PR and limit the installation options in the follow-up? |
Yes, since the feature is behind a Feature Flag I see no problem with addressing that on a follow-up PR |
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.
code changes LGTM, tested locally
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.
Fleet codeowner 🚀
Thanks for all the tests and the screencast - makes it very easy to approve. Code looks great.
dc55d19
to
48b5d37
Compare
Will wait till 8.12 is branched out to avoid having changes in the 8.12 codebase. The change is only relevant only for serverless, and to avoid any risk of breaking the release, will merge it into 8.13 main |
💛 Build succeeded, but was flaky
Failed CI StepsMetrics [docs]Module Count
Public APIs missing comments
Async chunks
Canvas Sharable Runtime
Page load bundle
History
To update your PR or re-run it, just comment with: |
## Summary Follow up after - #171671 Closes - elastic/security-team#7969 Includes: - limiting setup options for agentless to only Direct Access Keys and Temporary Keys - covering Agentless for edit flow ### How to test Make sure to have the FF in your `serverless.security.dev.yml` (it's similar to the `kibana.dev.yml` but specifically for Serverless Security Projects) enabled. Also specify some serverless project id, to enable the logic of `isServerlessEnabled` ``` xpack.fleet.enableExperimental: ['agentless'] xpack.cloud.serverless.project_id: 'some_fake_project_id' ``` The follow the steps from this comment elastic/security-team#7972 (comment) to have the Agentless artifacts (agent, policy, output, and fleet server host) locally After that, you should be able to test the flow. ### Screencast [screencast-mail.google.com-2023.12.08-16_37_35.webm](https://github.com/elastic/kibana/assets/478762/b94b685f-ed37-4e45-9907-bbd95cb8975a) ### Checklist Delete any items that are not applicable to this PR. - [x] Any text added follows [EUI's writing guidelines](https://elastic.github.io/eui/#/guidelines/writing), uses sentence case text and includes [i18n support](https://github.com/elastic/kibana/blob/main/packages/kbn-i18n/README.md) - [ ] [Documentation](https://www.elastic.co/guide/en/kibana/master/development-documentation.html) was added for features that require explanation or tutorials - [x] [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 - [ ] [Flaky Test Runner](https://ci-stats.kibana.dev/trigger_flaky_test_runner/1) was used on any tests changed - [ ] Any UI touched in this PR is usable by keyboard only (learn more about [keyboard accessibility](https://webaim.org/techniques/keyboard/)) - [ ] Any UI touched in this PR does not create any new axe failures (run axe in browser: [FF](https://addons.mozilla.org/en-US/firefox/addon/axe-devtools/), [Chrome](https://chrome.google.com/webstore/detail/axe-web-accessibility-tes/lhdoppojpmngadmnindnejefpokejbdd?hl=en-US)) - [ ] 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 renders correctly on smaller devices using a responsive layout. (You can test this [in your browser](https://www.browserstack.com/guide/responsive-testing-on-local-server)) - [ ] This was checked for [cross-browser compatibility](https://www.elastic.co/support/matrix#matrix_browsers) --------- Co-authored-by: kibanamachine <[email protected]>
…t policy (#173553) ## Summary Right now every Security project in serverless is created with [an Agentless policy](https://github.com/elastic/project-controller/blob/main/internal/project/security/security_kibana_config.go#L80) (gated be the feature flag based on or org id) and in this policy `is_managed` set to `false`. We in Cloud Security want to make the policy managed. This change is to allow us to do that and still be able to install integrations on the policy. In a nutshell, the logic is to force install integration if the agent policy id is `agentless`. If we are not missing something, it should be safe, as when managed, the agentless agent policy won't be available in the list of Existing Hosts and the only way to pick it for installation in the UI is to implement the same logic we implemented in CSP integration in - #171671 - #172562 Part of: - elastic/security-team#8117 ## Screencast https://github.com/elastic/security-team/assets/478762/c41f2f33-0c43-467f-a54a-8710b26a0abc ### Checklist Delete any items that are not applicable to this PR. - [x] [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
Summary
A part of
This PR doesn't cover the fact that with Agentless only
Manual - Direct Access Key
andManual - Temprary access key
are supported. Hiding other setup options, likeCloudformation
,Manual - Assume role
or Manual - Shared Credentials`, will be resolved in the next PR. As this feature is hidden behind a feature flag and based on the fact that Agentless is available only for a handful of internal Cloud org ids, it should be safe to merge this PR if code-wise it's ok.How to test
Make sure to have the FF in your
serverless.security.dev.yml
(it's basically thekibana.dev.yml
but specifically for Serverless Security Projects) enabled. Also specify some serverless project id, to enable the logic ofisServerlessEnabled
Follow the steps from this comment https://github.com/elastic/security-team/issues/7972#issuecomment-1808096052 to have the Agentless artifacts (agent, policy, output, and fleet server host) locally
After that, you should be able to test the flow. Mind that with agentless only
Manual - Direct Access Key
andManual - Temprary access key
setup methods are available. Hiding other options will be addressed in the follow upsScreencast
screencast-maxcold-agentless-selector-pr-b5b706.kb.eu-west-1.aws.qa.elastic.cloud-2023.11.27-10_30_57.webm
Checklist