Remove ExportData token permission if host-requests are disabled

[ernstvonoelsen]

…s-requests is true.

Description

summary of the change:
This PR validates the APITokens' scopes in case that a Dynakube instance is annotated with the alpha.operator.dynatrace.com/feature-disable-hosts-requests: "true" even if there is no ExportData permission (since this permission is never used in this case).

relevant motivation and context
Dynatrace Operator will be used in our enterprise landscape by several hundred teams to monitor their K8s clusters in a single-tenant Dynatrace Environment. Due to strict data privacy rules, we cannot allow that regular users get such broad read access on v1 API of Dynatrace as the ExportData permission scope would provide.
From my analysis of the code, the ExportData permission of the provided APIToken is never really required if
automatic kubernetes api monitoring is not enabled and the annotation alpha.operator.dynatrace.com/feature-disable-hosts-requests: "true" on the dynakube instance is present.

Since such a least-privilege approach is feasible without losing Dynatrace's monitoring capabilities (one only looses some comfort imho), I suggest to enable it also in code, although not making it the default.

How can this be tested?

What environment is necessary for the change to be noticeable ?
What needs to be enabled/applied for the change to be noticeable ?

• a dynakube secret with an APIToken that grants nothing else than InstallerDownload permissions
• the annotation feature.dynatrace.com/disable-hosts-requests: "true" on the dynakube instance
• instead of getting a missing scopes error on startup, the dynakube instance is spawned without any complaint

Checklist

• Unit tests have been updated/added
• PR is labeled accordingly

I was a bit too fast with my approval

[ernstvonoelsen]

Hi @meik99,
what are we missing?

[meik99]

I was just confused about an internal process, you're good

[ernstvonoelsen]

@meik99 any update on a merge date?

[ernstvonoelsen]

Hi @chrismuellner thank you for merging the latest master branch.

On which end do we have to fix the failing tests? Locally they are green, don't know where the difference stems from?

[chrismuellner]

1. You can fix the linting issues by running make lint
2. Tests seem to be failing for dtclient_reconciler_test which you modified. I'm assuming your logic changed the behavior for other tests. How are you running your tests? Running go test ./... should show what tests are failing.

[ernstvonoelsen]

Failing unittests updated (removed DeprecatedFeatureFlagPrefix to annotate the dk instance properly).

[chrismuellner]

Thanks! Just making sure the Actions run through before merging.