Adopt Secrets in Cloud Posture Management

[romulets]

What

Adopt Secrets in Cloud Posture Management

Based on elastic/package-spec#665 definition of what is possibly a secret the following the keys were labeled as secrets:

• cloudbeat/cis_eks
  • session_token
• cloudbeat/cis_aws
  • secret_access_key
• cloudbeat/cis_azure
  • azure.credentials.client_secret
  • azure.credentials.client_password
  • azure.credentials.client_certificate_password

Based on the criteria used of what potentially is a secret, more fields would have been classified as secret. Below you can find why they were not:

• cloudbeat/cis_eks
  • session_token
    • Not flagged as secret because it's a temporary token
• cloudbeat/cis_aws
  • session_token
    • Not flagged as secret because it's a temporary token

Why

Adoption of secrets is a kibana wide effort to remove the possibility of secrets leaks in kibana (via system logs/audit or humans)

Checklist

• I have reviewed tips for building integrations and this pull request is aligned with them.
• I have verified that all data streams collect metrics or logs.
• I have added an entry to my package's changelog.yml file.
• I have verified that Kibana version constraints are current according to guidelines.

Author's Checklist

• Test all integrations with secrets and validate that Posture Management still properly works

Related issues

• Closes https://github.com/elastic/security-team/issues/7380

Screenshots

Example of stored secret:

[elasticmachine]

💚 Build Succeeded

the below badges are clickable and redirect to their specific view in the CI or DOCS

Expand to view the summary

Build stats

• Start Time: 2023-12-04T13:20:55.350+0000

• Duration: 17 min 37 sec

Test stats 🧪

Test	Results
Failed	0
Passed	4
Skipped	0
Total	4

🤖 GitHub comments

Expand to view the GitHub comments

To re-run your PR in the CI, just comment with:

• /test : Re-trigger the build.

[elasticmachine]

🌐 Coverage report

Name	Metrics % (covered/total)	Diff
Packages	100.0% (0/0)	💚
Files	100.0% (0/0)	💚 21.429
Classes	100.0% (0/0)	💚 21.429
Methods	25.0% (2/8)	👎 -60.269
Lines	100.0% (0/0)	💚 14.149
Conditionals	100.0% (0/0)	💚

[jeniawhite]

@romulets
Looking at AWS V4 auth signature (https://docs.aws.amazon.com/IAM/latest/UserGuide/create-signed-request.html).
There is an X-Amz-Security-Token header that holds the session token (has to be provided as part of the request).
This header is part of the generated signed URL.
Due to that, I think that is it safe to assume that the session token is not a secret.
It looks like the behavior should be similar to the AWS access key ID (visible and present at the request as well).
I assume that AWS wouldn't assign it to signed URLs as a visible header if it should have been considered as a secret like the secret key ID.
We can still decide to treat them as secrets but I do not think that it is a must.

[romulets]

Tested with CSPM AWS.

Secrets are stored properly and properly retrieved in cloudbeat

Kibana configuration

Cloudbeat findings:

After a call with @amirbenun we agreed that testing one integration is enough, because cloudbeat doesn't do anything special to retrieve configurations our secrets. This piece is all automatically handled by the elastic/beats library and fleet-server implementation. Therefore if it works for one CSPM AWS, other CSPM and KSPM should have no further problems.

@oren-zohar do you agree with the above statement?

[elasticmachine]

Package cloud_security_posture - 1.7.0-preview07 containing this change is available at https://epr.elastic.co/search?package=cloud_security_posture

[elasticmachine]

Package cloud_security_posture - 1.7.0-preview08 containing this change is available at https://epr.elastic.co/search?package=cloud_security_posture