This pull request does not have a backport label. Could you fix it @AndersonQ? 🙏
To fixup this pull request, you need to add the backport labels for the needed
branches, such as:

• backport-./d./d is the label to automatically backport to the 8./d branch. /d is the digit

backport-v8.x has been added to help with the transition to the new branch 8.x.
If you don't need it please use backport-skip label and remove the backport-8.x label.

Pinging @elastic/elastic-agent-control-plane (Team:Elastic-Agent-Control-Plane)

I am worried about the performance of this component modifier. Most modifiers should just do some small movements or inject a little bit of extra configration.

This modifier is read a file and decrypting it every time the component model changes, which can be a lot. When using say the kubernetes provider with composable inputs it will recompute the model on every new pod state.

I believe this needs to be changed to only do that work once and only inject the cached content.

good point, even thought I'm not sure if defend would be used on such environments. Anyway I added a local cache for the component modifier and it's also thread-safe as the modifiers might be invoked from the coordinator main goroutine and for diagnostics as well.

This pull request is now in conflicts. Could you fix it? 🙏
To fixup this pull request, you can check out it locally. See documentation: https://help.github.com/articles/checking-out-pull-requests-locally/

git fetch upstream
git checkout -b 5490-pass-decrypted-cert-key-to-defend upstream/5490-pass-decrypted-cert-key-to-defend
git merge upstream/main
git push upstream 5490-pass-decrypted-cert-key-to-defend

/test

Quality Gate failed

Failed conditions
0.0% Coverage on New Code (required ≥ 40%)

See analysis details on SonarQube

Is there anywhere in our logs or diagnistcs .yaml files where the decrypted key could be logged accidentally (expected-config.yaml maybe)? Did we look through the diagnostics to check for this?

The file path likely won't be marked as a secret explicitly because it is obscured by default.

Is there anywhere in our logs or diagnistcs .yaml files where the decrypted key could be logged accidentally (expected-config.yaml maybe)? Did we look through the diagnostics to check for this?

The file path likely won't be marked as a secret explicitly because it is obscured by default.

Not really, the agent already accepts either a certificate or a filepath in the configuration and everything is correctly handled. The change here does not introduce anything new. So unless something was already leaking, I don't see hot the changes here would create a new leak.

However I must say I haven't done explicit test for that

However I must say I haven't done explicit test for that

I don't think we need a test, but a manual spot check searching through diagnostics should be done. Leaked TLS private keys is a bad time for everybody.

a manual spot check searching through diagnostics should be done. Leaked TLS private keys is a bad time for everybody.

we could add it to as a requirement on one of the manual tests for new releases. It'd cover this and any other change we might make