search

elastic / cloudbeat

Analyzing Cloud Security Posture
Other
39 stars 44 forks source link

[Cloud Connectors] [MVP] Configuration and Flow #2556

Open moukoublen opened 1 week ago

moukoublen commented 1 week ago

Motivation We need to create a separate configuration for cloud connectors. In that case an indication that cloud connectors is used should be provided (e.g. a enabled flag) and the customer remote-role arn should be also proved via configuration.

During the flow and if the cloud connectors is enabled, cloudbeat should first assume the implicit role provided by the EKS POD Identity association and then having assumed that cloudbeat should assume the customer remote role.

Using the credentials from the customer remote-role cloudbeat should continue to the scan flow.

POC branch: https://github.com/moukoublen/cloudbeat/tree/cc_8.14

Definition of done

Related tasks/epics Reference related issues and epics

eyalkraft commented 1 week ago

@moukoublen Are you sure we need a special case in cloudbeat for this flow? What would happen if we provide the user's role ARN on the role ARN authentication config option? would it fail? I'm just wondering if the first role would be implicitly assumed by the SDK which will then mean the second assume would succeed. wdyt?

This also has implications on how other integration could leverage cloud connectors. Ideally we wouldn't want to have to change every beat and beat to support it, but leverage the existing role-arn config option.

moukoublen commented 1 week ago

@eyalkraft I think for the remote assume to work we need a default config first (so aws SDK to get the token provided by the EKS Pod Identithy agent from the k8s mounted volume) using awsconfig.LoadDefaultConfig and then using that credentials (the elastic super-role) assume the remote one.

I think using the already implemented flow of "role arn to assume" didn't work for me in POC, but I didn't put the effort in, so perhaps it's something else that needs fixing.

So, I will check the flow of "role to assume" as it is implemented from `gibbet' further and post my findings here.

In any case, if we need to implement the described changes in cloudbeat, we could later on do that inside the "role to assume" flow of libbeat, and it would work for every beat.