[Cloud-Security] Adding var-groups to support authentication vars - related to cloud connector feature#16985
[Cloud-Security] Adding var-groups to support authentication vars - related to cloud connector feature#16985seanrathier wants to merge 0 commit intoelastic:mainfrom
Conversation
38a8b03 to
14f60c0
Compare
|
Pinging @elastic/integrations (Team:Integrations) |
|
Pinging @elastic/fleet (Team:Fleet) |
| vars: [role_arn, external_id] | ||
| hide_in_deployment_modes: [default] | ||
| provider: aws | ||
| iac_template_url: https://console.aws.amazon.com/cloudformation/home#/stacks/quickcreate?templateURL=https://elastic-cspm-cft.s3.eu-central-1.amazonaws.com/cloudformation-cloud-connectors-ACCOUNT_TYPE-9.2.0.yml¶m_ElasticResourceId=RESOURCE_ID |
There was a problem hiding this comment.
Is the point of the template to be public ?
User: arn:aws:sts::627286350134:assumed-role/okta-dev/michail.katsoulis@elastic.co is not authorized to perform: s3:ListBucket on resource: "arn:aws:s3:::elastic-cspm-cft" because no resource-based policy allows the s3:ListBucket action
There was a problem hiding this comment.
It is public but the Cloud Connector UI need to replace the ACCOUNT_TYPE and RESOURCE_ID in the URL. We will be adding a Cloud Connector Account Type selection in the Cloud Connector UI component to select it.
This is what we use in the CSPM and Cloud Asset Discovery Fleet extension to control the template URL.

| title: Collect Amazon GuardDuty logs via AWS S3 or SQS | ||
| description: Collecting Amazon GuardDuty logs via AWS S3 or SQS input. | ||
| hide_in_var_group_options: | ||
| credential_type: [cloud_connectors] |
There was a problem hiding this comment.
Is there an end goal for this?
There was a problem hiding this comment.
@MichaelKatsoulis thanks for the question.
The goal here
We currently have no way to identify group of vars represent, specifically for the use case when we refer to cloud provider credentials. This is why we are adding the var_groups.
hide_in_var_group_options are for inputs in the policy that don't support a var_group selection, in this case Cloud Connectors don't currently support S3 data collection.
This specific input you are referring does not support agentless either and cloud connectors can only work ATM with agentless agent deployments
The end goal
The end goals for all of this is to have credential vars when grouped together be required, allow us to know when are user to use the Cloud Connector feature so we can add some policy effects and the Cloud Connector UI
There was a problem hiding this comment.
Thank you @seanrathier for your detailed reply!
|
Pinging @elastic/security-service-integrations (Team:Security-Service Integrations) |
c5396d6 to
a42cf8f
Compare
|
Hi! We just realized that we haven't looked into this PR in a while. We're sorry! We're labeling this issue as |
agithomas
left a comment
There was a problem hiding this comment.
LGTM from obs packages. Kindly address the suggested changelog changes
|
/test |
andrewkroh
left a comment
There was a problem hiding this comment.
Please make sure you perform a manual test to validate the existing users on an earlier version of the aws guardduty package and seamlessly upgrade to the new version.
I think the big challenge with this change is going to be figuring out how we continue to support aws package users running Elastic stack 8.19.
| @@ -1,7 +1,7 @@ | |||
| format_version: 3.4.0 | |||
| format_version: 3.6.0 | |||
There was a problem hiding this comment.
The package now declares format_version: 3.6.0 while still allowing ^8.19.4 || ^9.2.1.
Per package-spec support guidance, 8.19 supports format 3.4 and 9.2 supports 3.5; 3.6 is not listed for those versions. (I'm not sure if those docs accurate, maybe 8.19 was updated?)
So some aspect of this is going to have to change.
There was a problem hiding this comment.
I bumped the version to ^9.3 but I think this needs a wider team discussion.
There was a problem hiding this comment.
I ran a test with 8.19.15-SNAPSHOT, and this new version of the aws package isn't visible on Kibana 8.19 because Kibana queries the elastic package-registry (EPR) with spec.max so it filters this release out.
https://epr.elastic.co/search?package=aws&spec.max=3.4&kibana.version=8.19.15
So even though we tested this version does work on 8.19 via directly upload, it won't work because the Kibana and EPR filter it out.
There was a problem hiding this comment.
@kpollich I think this is going to be a very common problem that we run into where we want to be able to continue delivering fixes for integrations to users that are on 8.19.x (while it is still officially under support) while also being able to adopt some newer package-spec features.
One solution is to bump the major version and drop support for 8.19 from the AWS package, but then we are signing up for maintaining an aws-6.x branch where we backport changes to the 8.19 users (where those changes are compatible with format_version: 3.4).
Providing maintenance to 8.19 users for all of the packages that want/need to move past format_version 3.4 could be a lot of work, especially since we have to do it for about ~14 months until July 2027.
Maybe you have some other ideas on how to handle this?
| elastic: | ||
| subscription: basic | ||
| kibana: | ||
| version: "^8.19.4 || ^9.2.1" |
There was a problem hiding this comment.
This PR switches GuardDuty httpjson auth to auth.aws, but package constraints still allow ^8.19.4 || ^9.2.1. But Beats httpjson only supports auth.aws from 9.3 onward.
There was a problem hiding this comment.
I bumped the version to ^9.3 but I think this needs a wider team discussion.
💚 Build Succeeded
History
cc @seanrathier |
|
/test stack 8.19.14-SNAPSHOT |
|
Quick update: |
d963f5d to
2bf8aab
Compare
💔 Build Failed
Failed CI StepsHistory
cc @seanrathier |
4e911c2 to
47bc590
Compare
Pull request was closed
|
Continued in #18762 — this PR could not be reopened (GitHub returned "no new commits on the seanrathier:var_groups branch" for both API and web reopen after the head branch was reset). The new PR uses the same head branch ( |
Summary
Adds
var_groupsconfiguration to the AWS integration package to enable a credential type selector in Fleet UI, improving the user experience when configuring AWS authentication methods.Related PRs
Changes
Added
var_groupssection to package manifest withcredential_typegroup containing:access_key_id,secret_access_key)access_key_id,secret_access_key,session_token)role_arn,external_id) - for agentless deploymentsrole_arn)role_arn,external_id)shared_credential_file,credential_profile_name)Added
hide_in_var_group_optionsto GuardDutyaws-s3input to hide Cloud Connector option (not supported for S3 input)Updated credential variables (
role_arn,external_id,shared_credential_file,credential_profile_name) toshow_user: trueso that users can see the vars in var group optionsScreenshots
Screen.Recording.2026-01-23.at.10.06.07.AM.mov
Related Issues
Checklist
changelog.ymlfile.Author's Checklist
How to test this PR locally