add missing kube-api resources from managed agent manifest

[oren-zohar]

What does this PR do?

In order for cloudbeat kube-api fetcher to work properly, we need to update the agent-managed manifest with permissions related to kube-api resources.

Checklist

• My code follows the style guidelines of this project
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation
• I have made corresponding change to the default configuration files
• I have added tests that prove my fix is effective or that my feature works
• I have added an entry in CHANGELOG.next.asciidoc or CHANGELOG-developer.next.asciidoc.

Related issues

• Relates: agent cloudbeat support #179
• Relates: https://github.com/elastic/security-team/issues/3682

[mergify]

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

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

NOTE: backport-skip has been added to this pull request.

[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: 2022-05-10T10:12:14.729+0000

• Duration: 20 min 37 sec

Test stats 🧪

Test	Results
Failed	0
Passed	3849
Skipped	21
Total	3870

🤖 GitHub comments

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

• /test : Re-trigger the build.

• /package : Generate the packages.

• run integration tests : Run the Elastic Agent Integration tests.

• run end-to-end tests : Generate the packages and run the E2E Tests.

• run elasticsearch-ci/docs : Re-trigger the docs validation. (use unformatted text in the comment!)

[ph]

@blakerouse or @ChrsMark Can you take a look?

[blakerouse]

I am going to have to defer to @ChrsMark, I do not know why it would need those permissions. Being that its related to that data-plane and not the control-plane (as Elastic Agent doesn't need that information for the the kubernetes dynamic input service).

[elasticmachine]

🌐 Coverage report

Name	Metrics % (covered/total)	Diff
Packages	95.652% (66/69)	👍
Files	69.524% (146/210)	👍
Classes	69.194% (292/422)	👍
Methods	52.493% (800/1524)	👍
Lines	38.726% (8596/22197)	👎 -0.005
Conditionals	100.0% (0/0)	💚

[ChrsMark]

We had a chat with @tonymeehan and it seems that we can proceed with this one for now and follow-up on documenting in detail why these permissions are needed and what happens if someone disable them. I think the most suitable place for this would be https://www.elastic.co/guide/en/fleet/master/running-on-kubernetes-managed-by-fleet.html.

Another thing that we need to think of is how we treat changes in those manifests and more specifically if a change in those manifests can be considered a breaking change for users. My perspective is that so far we didn't treat those manifests the similar way we do with core codebase regarding breaking changes which means that we can remove/update specs/settings even if that breaks things.

[oren-zohar]

@ChrsMark I opened an issue to track the documentation part. Merging is blocked for me so if you can please grant me merging rights or merge it yourself that would be great.

[ChrsMark]

This PR would require some extra changes so as to be merged:

1. I see that only the managed version is updated. Is this intentional? I would suggest ensuring same level of roles/permissions in both standalone and managed.
2. Files in https://github.com/elastic/elastic-agent/tree/main/deploy/kubernetes/elastic-agent-standalone and https://github.com/elastic/elastic-agent/tree/main/deploy/kubernetes/elastic-agent-managed should be updated too properly. Actually changes should take place first in these files and then running make all at top level should update the full files too. This should had been catched by our CI here, since it was like this in Beats repo. @narph do you know why this is not happening here?

[ChrsMark]

Overall looks good. However we need to make sure that process of updating these files is robust by using make all and that CI will ensure that no inconsistencies exist (cc: @narph )

[ChrsMark]

@narph it seems that this was needed so as to the make all to generate the proper final manifests. Could you verify this please? Also we need to figure out why the CI didn't complain about the previous commits.

[narph]

this pr #417 should update version and add check in CI