fix: Add key vault to cognitive service - avm/res/cognitive-services/account

[Agazoth]

Description

Add option for outputting keys to key vault

Pipeline Reference

Pipeline

Type of Change

• Update to CI Environment or utlities (Non-module effecting changes)
• Azure Verified Module updates:
  • Bugfix containing backwards compatible bug fixes, and I have NOT bumped the MAJOR or MINOR version in version.json:
    • 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, and I have bumped the MINOR version in version.json.
  • Breaking changes and I have bumped the MAJOR version in version.json.
  • Update to documentation

Checklist

• I'm sure there are no other open Pull Requests for the same update/change
• I have run Set-AVMModule locally to generate the supporting module files.
• My corresponding pipelines / checks run clean and green without any errors or warnings

[eriqua]

Hey @Agazoth thanks for the active contribution, keep it up 💪
A general comment from my side:
Adding resource types which are not part of the primary resource type hierarchy of the module is usually borderline a resource module. In many cases, while discussing, we can realize that a pattern (ptn) module would be a better fit. Since this is the second PR with a similar approach, I'd suggest to open a GitHub issue explaining the intention of this addition, so that we can discuss there and identify for example:

• which module type would be the best fit (res or ptn)
• the best way to implement (naming, interface etc)
• plan accordingly if needed to be adopted by other modules.

[ilhaan]

There is a discussion about the right approach for resources that emit secrets: #1934 - posting here for visibility

[ilhaan]

Discussion still ongoing #1934

[AlexanderSehr]

Hey @Agazoth, you can ignore the failed job. It's due to a bug which is addressed by this PR #3038

[AlexanderSehr]

Looks good form my side. @ilhaan / @jceval, any doubts?

[jceval]

No doubts. After reading through the discussion - I agree on all points from the arrived upon option and implementation.
@Agazoth PR looks good to me

[AlexanderSehr]

I'll merge the PR in once #3038 is merged as the pipeline will otherwise fail

@ChrisSidebotham / @jtracey93 / @eriqua a review would be much appreciated :)

[ilhaan]

#3038 has merged @AlexanderSehr

The pipeline badge is red @Agazoth

[AlexanderSehr]

#3038 has merged @AlexanderSehr

The pipeline badge is red @Agazoth

@Agazoth, I believe it's an issue a Re-Run of the failed job should fix. That said, I'd also recommend to re-run the Set-AVMModule script once as there were some readme updates since this PR was opened.

[AlexanderSehr]

@Agazoth,
because I just saw it happen in your fork - let me direct your attention to one very useful workflow you should run in your fork at least once (but it wouldn't hurt to do it from time to time again to also cover new modules): https://azure.github.io/Azure-Verified-Modules/contributing/bicep/bicep-contribution-flow/enable-or-disable-workflows/

All workflows have a trigger on main as that's what kicks the publishing off. As re-syncs with upstream are not unheard of, we created the linked workflow (you can find in your list of workflows in your fork) to disable all workflows. This has the benefit that you can enable individual workflows as you need them, while no others are triggered - ever again. 💪

[Agazoth]

@Agazoth, because I just saw it happen in your fork - let me direct your attention to one very useful workflow you should run in your fork at least once (but it wouldn't hurt to do it from time to time again to also cover new modules): https://azure.github.io/Azure-Verified-Modules/contributing/bicep/bicep-contribution-flow/enable-or-disable-workflows/

All workflows have a trigger on main as that's what kicks the publishing off. As re-syncs with upstream are not unheard of, we created the linked workflow (you can find in your list of workflows in your fork) to disable all workflows. This has the benefit that you can enable individual workflows as you need them, while no others are triggered - ever again. 💪

You are absolutely right, @AlexanderSehr and thank you for this! I have become pretty shavvy with the github cli now though 😄 - right now I am trying to convince Github actions to use a new subscription (I updated the Secrets with a new subscriptionid) but it is as if the old subscriptionid is stuck somewhere, and my google-fu seems to be weak today. There is no obvious setting that either cashes or force updates the secrets used in the workflow.

[AlexanderSehr]

@Agazoth, because I just saw it happen in your fork - let me direct your attention to one very useful workflow you should run in your fork at least once (but it wouldn't hurt to do it from time to time again to also cover new modules): https://azure.github.io/Azure-Verified-Modules/contributing/bicep/bicep-contribution-flow/enable-or-disable-workflows/
All workflows have a trigger on main as that's what kicks the publishing off. As re-syncs with upstream are not unheard of, we created the linked workflow (you can find in your list of workflows in your fork) to disable all workflows. This has the benefit that you can enable individual workflows as you need them, while no others are triggered - ever again. 💪

You are absolutely right, @AlexanderSehr and thank you for this! I have become pretty shavvy with the github cli now though 😄 - right now I am trying to convince Github actions to use a new subscription (I updated the Secrets with a new subscriptionid) but it is as if the old subscriptionid is stuck somewhere, and my google-fu seems to be weak today. There is no obvious setting that either cashes or force updates the secrets used in the workflow.

That's indeed strange. Once you update the secrets, it should pick up on the new subscription immediately. :o

[Agazoth]

@Agazoth, because I just saw it happen in your fork - let me direct your attention to one very useful workflow you should run in your fork at least once (but it wouldn't hurt to do it from time to time again to also cover new modules): https://azure.github.io/Azure-Verified-Modules/contributing/bicep/bicep-contribution-flow/enable-or-disable-workflows/
All workflows have a trigger on main as that's what kicks the publishing off. As re-syncs with upstream are not unheard of, we created the linked workflow (you can find in your list of workflows in your fork) to disable all workflows. This has the benefit that you can enable individual workflows as you need them, while no others are triggered - ever again. 💪

You are absolutely right, @AlexanderSehr and thank you for this! I have become pretty shavvy with the github cli now though 😄 - right now I am trying to convince Github actions to use a new subscription (I updated the Secrets with a new subscriptionid) but it is as if the old subscriptionid is stuck somewhere, and my google-fu seems to be weak today. There is no obvious setting that either cashes or force updates the secrets used in the workflow.

That's indeed strange. Once you update the secrets, it should pick up on the new subscription immediately. :o

I think I have to file a bug report at Github. I have tried just about everything - including deleting - and the Action still knows the old subscriptionid. However much I wnat to close this PR now, it seems to have to wait until that wierd issue is solved. I'll follow up and update here once the issue is solved and the pipeline runs.

[AlexanderSehr]

@Agazoth, because I just saw it happen in your fork - let me direct your attention to one very useful workflow you should run in your fork at least once (but it wouldn't hurt to do it from time to time again to also cover new modules): https://azure.github.io/Azure-Verified-Modules/contributing/bicep/bicep-contribution-flow/enable-or-disable-workflows/
All workflows have a trigger on main as that's what kicks the publishing off. As re-syncs with upstream are not unheard of, we created the linked workflow (you can find in your list of workflows in your fork) to disable all workflows. This has the benefit that you can enable individual workflows as you need them, while no others are triggered - ever again. 💪

You are absolutely right, @AlexanderSehr and thank you for this! I have become pretty shavvy with the github cli now though 😄 - right now I am trying to convince Github actions to use a new subscription (I updated the Secrets with a new subscriptionid) but it is as if the old subscriptionid is stuck somewhere, and my google-fu seems to be weak today. There is no obvious setting that either cashes or force updates the secrets used in the workflow.

That's indeed strange. Once you update the secrets, it should pick up on the new subscription immediately. :o

I think I have to file a bug report at Github. I have tried just about everything - including deleting - and the Action still knows the old subscriptionid. However much I wnat to close this PR now, it seems to have to wait until that wierd issue is solved. I'll follow up and update here once the issue is solved and the pipeline runs.

@Agazoth while you're try to resolve this - we could also take a detour and merge your PR into a branch in upstream from where I re-test it - and re-open it as a new PR. Git-history-wise you'd still be the author.

[Agazoth]

@Agazoth, because I just saw it happen in your fork - let me direct your attention to one very useful workflow you should run in your fork at least once (but it wouldn't hurt to do it from time to time again to also cover new modules): https://azure.github.io/Azure-Verified-Modules/contributing/bicep/bicep-contribution-flow/enable-or-disable-workflows/
All workflows have a trigger on main as that's what kicks the publishing off. As re-syncs with upstream are not unheard of, we created the linked workflow (you can find in your list of workflows in your fork) to disable all workflows. This has the benefit that you can enable individual workflows as you need them, while no others are triggered - ever again. 💪

You are absolutely right, @AlexanderSehr and thank you for this! I have become pretty shavvy with the github cli now though 😄 - right now I am trying to convince Github actions to use a new subscription (I updated the Secrets with a new subscriptionid) but it is as if the old subscriptionid is stuck somewhere, and my google-fu seems to be weak today. There is no obvious setting that either cashes or force updates the secrets used in the workflow.

That's indeed strange. Once you update the secrets, it should pick up on the new subscription immediately. :o

I think I have to file a bug report at Github. I have tried just about everything - including deleting - and the Action still knows the old subscriptionid. However much I wnat to close this PR now, it seems to have to wait until that wierd issue is solved. I'll follow up and update here once the issue is solved and the pipeline runs.

@Agazoth while you're try to resolve this - we could also take a detour and merge your PR into a branch in upstream from where I re-test it - and re-open it as a new PR. Git-history-wise you'd still be the author.

I would be perfectly fine with that 😃

[AlexanderSehr]

Off we go then.

[Agazoth]

@AlexanderSehr I figured it out. I only updated the subscription in ARM_SUBSCRIPTION_ID without updating the AZURE_CREDENTIALS. RTFM is still a thing, I guess 😆 - maybe AZURE_CREDENTIALS should only contain secrets not already covered by other secrets?

[AlexanderSehr]

Hey @Agazoth,
I'll do you one better - outside very view exceptions, we'll soon enable OIDC authentication thanks to @eriqua's work in this PR: #2792. With it you won't need a credential to begin wih 💪
That said, AZURE_CREDENTIALS is set up in the way it is because it's directly consumed by the login task in the pipeline. In other words, we don't have a task before the login to manipulate the value (and e.g., inject the subscription id).

[Agazoth]

That is awesome!