AKS manifest placement

[geoberle]

add a module aks-manifest.bicep to manage resources on AKS clusters. this can be used to

• create expected Namespaces
• create exüected ServiceAccounts with MIWI annotations for cloud resource access via Entra
• create expected ConfigMaps and Secrets holding configuration information for cloud resources, e.g. DB hostnames, ...

An example usage can be seen in the aks-cluster-base.bicep template, where the namespace and serviceaccount are created for each federated managed identity.

The current way to apply the manifests relies on a network path to the cluster. For private clusters we have the following options:

• use az aks command invoke - experiments resulted in MissingAADClusterToken when run within a deploymentscript
• run the container instance of the deploymentscript within a VNET that has a network path to the cluster

part of SD-DDR-0030 and https://issues.redhat.com/browse/ARO-7249

What this PR does

Before this PR:

After this PR:

Jira:
Link to demo recording:

Special notes for your reviewer

Checklist

This checklist is not enforcing, but it's a reminder of items that could be relevant to every PR.
Approvers are expected to review this list.

• PR: The PR description is expressive enough and will help future contributors
• Code: Write code that humans can understand and Keep it simple
• Refactor: You have left the code cleaner than you found it (Boy Scout Rule)
• Upgrade: Impact of this change on upgrade flows was considered and addressed if required
• Deployment: The deployment process was considered and addressed if required
• Testing: New code requires new unit tests.
• Documentation: Is the documentation updated? Either in the doc located in focus area, in the README or in the code itself.
• Customers: Is this change affecting customers? Is the release plan considered?