search

Azure / Azure-Verified-Modules

Azure Verified Modules (AVM) is an initiative to consolidate and set the standards for what a good Infrastructure-as-Code module looks like. Modules will then align to these standards, across languages (Bicep, Terraform etc.) and will then be classified as AVMs and available from their respective language specific registries.
https://aka.ms/AVM
MIT License
333 stars 71 forks source link

[Module Proposal]: `avm/ptn/deployment-script/private` #995

Open johnlokerse opened 4 months ago

johnlokerse commented 4 months ago

Check for previous/existing GitHub issues/module proposals

Check this module doesn't already exist in the module indexes

Bicep or Terraform?

Bicep

Module Classification?

Pattern Module

Module Name

avm/ptn/deployment-script/private

Module Details

It would be great to have a pattern module for private deployment scripts. There is some required infrastructure and configuration to be able to run deployment scripts over private endpoints. (see image below)

The pattern module must require flexibility in providing resource references. For example for Private DNS Zone, either deploy one or give a resourceId of an existing zone since this can be environment specific.

image

Do you want to be the owner of this module?

No

Module Owner's GitHub Username (handle)

@sebassem (Seif Bassem)

(Optional) Secondary Module Owner's GitHub Username (handle)

No response

johnlokerse commented 4 months ago

Tagged Seif Bassem @sebassem as module owner 😃

matebarabas commented 4 months ago

@johnlokerse, thank you for proposing this module! As this is categorized as a pattern module, its approval will require a more thorough assessment. The AVM core team will get back to you soon. Thank you for your patience!

@sebassem, I pinged you some questions internally.

johnlokerse commented 4 months ago

@sebassem If you want to talk or have questions about the solution just send me a message just ask them on Teams (or here 😃). I already have something on the shelf, just need to add the AVM code convention and maybe some flexibility in choosing if you want to use a new or existing private DNS zone.

sebassem commented 4 months ago

@sebassem If you want to talk or have questions about the solution just send me a message just ask them on Teams (or here 😃). I already have something on the shelf, just need to add the AVM code convention and maybe some flexibility in choosing if you want to use a new or existing private DNS zone.

Sure thing, once the AVM core team triages the request I will reach out to chat

AlexanderSehr commented 3 months ago

Hey @johnlokerse, I hope you're well. Want to share / ask my 50 cents here as well as I've been using the deployment script with private networking in one of my solutions too (not using the AVM module yet though, but the original CARML one).

Anyhow - I'm struggle a bit to understand what the pattern would do in addition to what the resource module can do today. One thing I can see is that it does not deploy the private networking resources itself (e.g.., not the VNET, nor a private endpoint etc.) - but instead expects the user to just provide the subnet ID to deploy the container into, assuming that the rest is set up. Woud this pattern then also deploy the deployment script's storage account including that private endpoint & DNS entry? Up until now I've only been using a ServiceEndpoint for this storage account (like the example in the module itself), but a private endpoint would of course be nice as an alternative. However, if the case - then one could argue it should be just that, an option, because many customers maintain a central DNS instance.

Similar questions could be asked about an existing MSI, VNET etc. I wonder how flexible you can implement this 😉

johnlokerse commented 3 months ago

Hey @AlexanderSehr, thanks for the reply 👍! I see your point, and maybe I have misunderstood the purpose of a pattern module.

Yes, flexibility is a must here. The end goal of this pattern module is to setup everything required for running a deployment script "over a private endpoint". It's basically an Azure Container Instance which runs the script and has a private connection with the storage account instead of using a service endpoint.

This pattern would contain the following resources:

Something to discuss about is the deployment script resource itself (which deploys the Azure Container Instance). Would this be something for the pattern module or is it using the resources created by the pattern module. What do you guys think?

Depending on how we see it, this pattern could be a wrapper of resources (bad) or it could be offered as a standalone solution (with options to integrate into existing components) (good) to deploy within their Azure landscape:

image

It will be quite some work to get this done, especially with the requirement to integrate into various services. Isn't every pattern module a challenge on this part though? I can imagine that every Azure environment has their own unique requirement.

AlexanderSehr commented 3 months ago

Hey @AlexanderSehr, thanks for the reply 👍! I see your point, and maybe I have misunderstood the purpose of a pattern module.

Yes, flexibility is a must here. The end goal of this pattern module is to setup everything required for running a deployment script "over a private endpoint". It's basically an Azure Container Instance which runs the script and has a private connection with the storage account instead of using a service endpoint.

This pattern would contain the following resources:

  • Virtual network with 2 subnets (for container and private endpoint)
  • Storage account with publicAccess disabled
  • Private endpoint configured on storage account (file)
  • [optional due to centralisation (or through DINE policy)] Private DNS zone file.core.windows.net with the PE registered
  • User-assigned managed identity with permissions on the storage account

Something to discuss about is the deployment script resource itself (which deploys the Azure Container Instance). Would this be something for the pattern module or is it using the resources created by the pattern module. What do you guys think?

Depending on how we see it, this pattern could be a wrapper of resources (bad) or it could be offered as a standalone solution (with options to integrate into existing components) (good) to deploy within their Azure landscape:

image

It will be quite some work to get this done, especially with the requirement to integrate into various services. Isn't every pattern module a challenge on this part though? I can imagine that every Azure environment has their own unique requirement.

Hey @johnlokerse, thanks for the detailed reply. Makes sense to me - as long as we can keep it flexible (at at least start with some flexibility and expand in it over time as per demand. For example existing MSI vs new MSI, existing VNET vs new VNET, prexisting DNS vs new DNS etc.).

I think it's a good use case for a pattern module, and should not only deploy the dependencies but definitely also the deployment script itself (if I understood your question correctly). While doing so, it should use AVM modules whereever possible.

johnlokerse commented 3 months ago

Hey @AlexanderSehr, thanks for the reply 👍! I see your point, and maybe I have misunderstood the purpose of a pattern module. Yes, flexibility is a must here. The end goal of this pattern module is to setup everything required for running a deployment script "over a private endpoint". It's basically an Azure Container Instance which runs the script and has a private connection with the storage account instead of using a service endpoint. This pattern would contain the following resources:

  • Virtual network with 2 subnets (for container and private endpoint)
  • Storage account with publicAccess disabled
  • Private endpoint configured on storage account (file)
  • [optional due to centralisation (or through DINE policy)] Private DNS zone file.core.windows.net with the PE registered
  • User-assigned managed identity with permissions on the storage account

Something to discuss about is the deployment script resource itself (which deploys the Azure Container Instance). Would this be something for the pattern module or is it using the resources created by the pattern module. What do you guys think? Depending on how we see it, this pattern could be a wrapper of resources (bad) or it could be offered as a standalone solution (with options to integrate into existing components) (good) to deploy within their Azure landscape: image It will be quite some work to get this done, especially with the requirement to integrate into various services. Isn't every pattern module a challenge on this part though? I can imagine that every Azure environment has their own unique requirement.

Hey @johnlokerse, thanks for the detailed reply. Makes sense to me - as long as we can keep it flexible (at at least start with some flexibility and expand in it over time as per demand. For example existing MSI vs new MSI, existing VNET vs new VNET, prexisting DNS vs new DNS etc.).

I think it's a good use case for a pattern module, and should not only deploy the dependencies but definitely also the deployment script itself (if I understood your question correctly). While doing so, it should use AVM modules whereever possible.

@AlexanderSehr Yes, dependencies + deployment script itself would be good

When the pattern module can handle the infrastructure like you mentioned @AlexanderSehr and it has constraints to mitigate errors such as on this list: https://learn.microsoft.com/en-us/azure/azure-resource-manager/bicep/deployment-script-bicep?tabs=CLI#deployment-script-error-codes then it's a great addition as a pattern module, where the user doesn't have to deal with figuring out how the private deployment script work. 😄

matebarabas commented 3 months ago

Thanks for the great conversation, @johnlokerse and @AlexanderSehr! It sounds like the most important details were clarified, and we can proceed with this module, provided it will be developed in a flexible way.

@sebassem, are you ready to take "administrative" ownership and support @johnlokerse in developing this module?

Thanks!

AlexanderSehr commented 3 months ago

(...)

Hey @johnlokerse, thanks for the detailed reply. Makes sense to me - as long as we can keep it flexible (at at least start with some flexibility and expand in it over time as per demand. For example existing MSI vs new MSI, existing VNET vs new VNET, prexisting DNS vs new DNS etc.). I think it's a good use case for a pattern module, and should not only deploy the dependencies but definitely also the deployment script itself (if I understood your question correctly). While doing so, it should use AVM modules whereever possible.

@AlexanderSehr Yes, dependencies + deployment script itself would be good

When the pattern module can handle the infrastructure like you mentioned @AlexanderSehr and it has constraints to mitigate errors such as on this list: https://learn.microsoft.com/en-us/azure/azure-resource-manager/bicep/deployment-script-bicep?tabs=CLI#deployment-script-error-codes then it's a great addition as a pattern module, where the user doesn't have to deal with figuring out how the private deployment script work. 😄

Might be a good idea to also add any applicable learnings to the private networking test of the deployment script module too. I see those scenario-based tests (e.g., like this one, or for encryption etc.) always as a great reference. (cc: @sebassem)

johnlokerse commented 3 months ago

@sebassem A heads up - I am on holiday leave for the upcoming two weeks, so I am not able to respond to messages. Luckily my PR for article https://learn.microsoft.com/en-us/azure/azure-resource-manager/bicep/deployment-script-vnet-private-endpoint has been approved and will provide the base and a starting point of the pattern module.

sebassem commented 3 months ago

@sebassem A heads up - I am on holiday leave for the upcoming two weeks, so I am not able to respond to messages. Luckily my PR for article https://learn.microsoft.com/en-us/azure/azure-resource-manager/bicep/deployment-script-vnet-private-endpoint has been approved and will provide the base and a starting point of the pattern module.

No worries, I'm out as well till July. Let's sync once we are both back

matebarabas commented 3 months ago

Until then, let's do the handshake, @sebassem, whenever you're ready! ;)

matebarabas commented 3 months ago

Hi @sebassem,

Thanks for requesting/proposing to be an AVM module owner!

We just want to confirm you agree to the below pages that define what module ownership means:

Any questions or clarifications needed, let us know!

If you agree, please just reply to this issue with the exact sentence below (as this helps with our automation 👍):

"I CONFIRM I WISH TO OWN THIS AVM MODULE AND UNDERSTAND THE REQUIREMENTS AND DEFINITION OF A MODULE OWNER"

Thanks,

The AVM Core Team

RR

segraef commented 3 months ago

@johnlokerse, thanks for the module proposal. I just want to bring one item to your attention which might help and maybe you faced it already. It would also be good to create a note for the ptn module consumer then later.

The AVM SA allows shared key access by default by default but some enterprise customer policies (your point about "... [optional due to centralisation (or through DINE policy)] Private DNS zone ..." reminded me of it) deny the usage of SAS in general. If that's the case the deployment of the ACI will fail while it's trying to map the file storage because it requires SAS. The error DeploymentScriptACIProvisioningTimeout can't be found here.

image

Some context in addition: https://github.com/MicrosoftDocs/azure-docs/issues/120857. Remember this is for the DS Access private virtual network but as you know but the same setting (to allow SAS) applies to the DS Use over private endpoint: https://learn.microsoft.com/en-us/azure/azure-resource-manager/bicep/deployment-script-vnet-private-endpoint.

sebassem commented 3 months ago

I CONFIRM I WISH TO OWN THIS AVM MODULE AND UNDERSTAND THE REQUIREMENTS AND DEFINITION OF A MODULE OWNER

I CONFIRM I WISH TO OWN THIS AVM MODULE AND UNDERSTAND THE REQUIREMENTS AND DEFINITION OF A MODULE OWNER

matebarabas commented 3 months ago

Hi @sebassem,

Thanks for confirming that you wish to own this AVM module and understand the related requirements and responsibilities!

Before starting development, please ensure ALL the following requirements are met.

Please use the following values explicitly as provided in the module index page:

Check if this module exists in the other IaC language. If so, collaborate with the other owner for consistency. 👍

You can now start the development of this module! ✅ Happy coding! 🎉

Please respond to this comment and request a review from the AVM core team once your module is ready to be published! Please include a link pointing to your PR, once available. 🙏

Any further questions or clarifications needed, let us know!

Thanks,

The AVM Core Team

sebassem commented 3 months ago

@johnlokerse Lets sync next week when you have time to chat about this module

johnlokerse commented 3 months ago

@sebassem Yes, let's do that! I will send you a message next week 😄

@segraef Thanks for the heads-up! 💪

johnlokerse commented 2 months ago

@sebassem

I tried to reach out on Teams, but I couldn't find you in the Microsoft tenant. I wanted to share an outline of work with you that I have to do:

Am I missing something on this list? 😃

sebassem commented 2 months ago

@sebassem

I tried to reach out on Teams, but I couldn't find you in the Microsoft tenant. I wanted to share an outline of work with you that I have to do:

  • [ ] Adjust the Bicep template to adhere AVM standards
  • [ ] Add telemetry module
  • [ ] Add @description to parameters and outputs
  • [ ] Implement tests for e2e/waf-aligned
  • [ ] Implement tests for e2e/max
  • [ ] Implement tests for e2e/defaults
  • [ ] Generate readme
  • [ ] Use UDTs whenever possible
  • [ ] Implement GitHub Action and deploy to subscription
  • [ ] Add version.json

Am I missing something on this list? 😃

Looks great, one thing I would add it add more tests for different scenarios if applicable like the current deployment script module. My alias is sebassem@microsoft.com, if you don't find me, we can use another method to chat or work async.

johnlokerse commented 2 months ago

@sebassem

I tried to reach out on Teams, but I couldn't find you in the Microsoft tenant. I wanted to share an outline of work with you that I have to do:

  • [ ] Adjust the Bicep template to adhere AVM standards

  • [ ] Add telemetry module

  • [ ] Add @description to parameters and outputs

  • [ ] Implement tests for e2e/waf-aligned

  • [ ] Implement tests for e2e/max

  • [ ] Implement tests for e2e/defaults

  • [ ] Generate readme

  • [ ] Use UDTs whenever possible

  • [ ] Implement GitHub Action and deploy to subscription

  • [ ] Add version.json

Am I missing something on this list? 😃

Looks great, one thing I would add it add more tests for different scenarios if applicable like the current deployment script module. My alias is sebassem@microsoft.com, if you don't find me, we can use another method to chat or work async.

I reached out to you on LinkedIn because 404 Seif not found in the Microsoft teams tenant...

Also a bit late, but I wanted to reach out last week, but had some other stuff on my plate that held me busy 😃

sebassem commented 1 month ago

Work in progress

sebassem commented 1 month ago

This will be long term