updates to make module more production ready

[kewalaka]

Description

@nellyk in response to your question, whether I have done any work on this.

I haven't had chance to break this down into multiple PRs, but we ran into a number of issues using this module, that this change addresses. I realise some are cosmetic. I also realise its a large PR.

Change highlights

• allowed all resources to be named, or based off the base resource name if not supplied
• allowed the option to 'bring you own resource' - this is particularly important for things like LAW, which MIcrosoft recommend to be centralised.
• added monitoring
• many features that would be required for production deployments were not accessible, see below for specifics. I've aimed for sensible, CAF-aligned defaults to keep the required inputs down.

In order of changes below:

• private_dns_zone_id_enabled is a bit misleading and has been renamed to private_dns_zone_set_rbac_permissions which is actually what it does.
• in the examples, name should be used rather than kubernetes_name
• i added an example for testing without acr, because we didn't need it.
• I've added monitoring that aligns with the AKS Automatic portal experience. This can be conditionally switch on/off via feature flags
• the outputs are not aligned to the AVM spec. They shoudl not include the resource object, but should include all computed attributes. I think what I have is correct (it's certainly closer!)
• terraform_data is the generally preferred replacement for your use of the null provider
• all components names can now be specified by the caller. To make the number of required parameters manageable, these are computed off the base name of the cluster in locals, but can be overridden, as is required by the spec (and many orgs would mandate this)
• I've added vars for features that should reasonably be expected to be enabled, again adding defaults to reduce usage, these are image cleaner, optional VNET inegration, keda, maintenance windows, control over the max_count, the MS defender LAW ID, network policy, pod autoscaling, an optional ingress profile (tested with the managed nginx ingress), safeguard_profile
• CAF alignment of defaults - rbac_aad_azure_rbac_enabled now defaults to true.
• pre-existing resources can optionally be provided - e.g. if you provide a resource ID for LAW, that is used. This is a nearly universal requirement in corporates, as Microsoft recommend a centralised LAW.

The above lints & changes currently in main have been merge into it.

closing notes

I don't usually like to PR changes this large, unfortunately time constraints have meant I haven't had chance to do this in stages.

That, and I suspect some of the above you may not agree with.

I understand you're wanting to make some decisions for the caller, but in our use of this we found it too restrictive to be useful, and I propose that are requirements are not going to be especially unusual.

Happy for discussions....

Type of Change

• Non-module change (e.g. CI/CD, documentation, etc.)
• Azure Verified Module updates:
  • Bugfix containing backwards compatible bug fixes
    • Someone has opened a bug report issue, and I have included "Closes #{bug_report_issue_number}" in the PR description.
    • The bug was found by the module author, and no one has opened an issue to report it yet.
  • Feature update backwards compatible feature updates.
  • Breaking changes.
  • Update to documentation

Checklist

• I'm sure there are no other open Pull Requests for the same update/change
• My corresponding pipelines / checks run clean and green without any errors or warnings
• I did run all pre-commit checks

[kewalaka]

if you do find the useful, I would suggest we land it in a different branch, not main, so we can do some isolated testing.

for my scenario, this is working well, but I haven't regression tested it.

i'm also aware of the resource module being worked on too, thus I didn't want ot waste time on this if the ptn module is going to get refactored to re-use this new resource module.

[kewalaka]

if this is of general use, but the monitoring adds to much noise, i'm happy to split that out. However if it's not in the direction you want to go, I'd rather you say so, please.