Closed vishal-1908 closed 1 month ago
[!IMPORTANT] The "Needs: Triage :mag:" label must be removed once the triage process is complete!
[!TIP] For additional guidance on how to triage this issue/PR, see the BRM Issue Triage documentation.
[!WARNING] Tagging the AVM Core Team (@Azure/avm-core-team-technical-bicep) due to a module owner or contributor having not responded to this issue within 3 business days. The AVM Core Team will attempt to contact the module owners/contributors directly.
[!TIP]
- To prevent further actions to take effect, the "Status: Response Overdue 🚩" label must be removed, once this issue has been responded to.
- To avoid this rule being (re)triggered, the ""Needs: Triage :mag:" label must be removed as part of the triage process (when the issue is first responded to)!
Hey @tsc-buddy & @pankajagrawal16, just assigned you to the issue. Please triage it when you have a moment :)
[!WARNING] Tagging the AVM Core Team (@Azure/avm-core-team-technical-bicep) due to a module owner or contributor having not responded to this issue within 3 business days. The AVM Core Team will attempt to contact the module owners/contributors directly.
[!TIP]
- To prevent further actions to take effect, the "Status: Response Overdue 🚩" label must be removed, once this issue has been responded to.
- To avoid this rule being (re)triggered, the ""Needs: Triage :mag:" label must be removed as part of the triage process (when the issue is first responded to)!
[!CAUTION] This issue requires the AVM Core Team's (@Azure/avm-core-team-technical-bicep) immediate attention as it hasn't been responded to within 6 business days.
[!TIP]
- To avoid this rule being (re)triggered, the "Needs: Triage :mag:" and "Status: Response Overdue :triangular_flag_on_post:" labels must be removed when the issue is first responded to!
- Remove the "Needs: Immediate Attention :bangbang:" label once the issue has been responded to.
@AlexanderSehr Yes i will have a look
Hi @vishal-1908
I looked through the issue, and i have a question.
Currently module accepts siteConfig
as an object, so you can basically pass any properties supported as part of siteconfig
to the module which off-course includes ipSecurityRestriction
and scmIpSecurityRestriction
as well.
Have you tried passing these configuration inside siteConfig as documented here ?
Please confirm.
[!IMPORTANT] @vishal-1908, this issue has been automatically marked as stale because it has been marked as requiring author feedback but has not had any activity for 4 days. It will be closed if no further activity occurs within 3 days of this comment.
[!TIP] To prevent further actions to take effect, one of the following conditions must be met:
- The author must respond in a comment within 3 days of this comment.
- The "Status: No Recent Activity :zzz:" label must be removed.
- If applicable, the "Status: Long Term :hourglass_flowing_sand:" or the "Needs: Module Owner :mega:" label must be added.
[!WARNING] @vishal-1908, this issue will now be closed, as it has been marked as requiring author feedback but has not had any activity for 7 days.
[!TIP] In case this issue needs to be reopened (e.g., the author responds after the issue was closed), the "Status: No Recent Activity :zzz:" label must be removed.
Check for previous/existing GitHub issues
Issue Type?
Feature Request
Module Name
avm/res/web/site
(Optional) Module Version
No response
Description
Description:
I encountered an issue while attempting to deploy an Azure Function App from my IDE. The deployment fails due to the function app's public network access being disabled. This issue arises when a private endpoint is configured for the function app, resulting in the absence of
ipSecurityRestrictions
settings.Reproduction Steps:
Expected Behavior: The function app should be deployable from the IDE, with the appropriate
ipSecurityRestrictions
in place.Actual Behavior: The deployment is blocked because public network access is disabled, and
ipSecurityRestrictions
are missing fromavm/res/web/site:version
. This configuration issue can currently only be resolved by manually addingipSecurityRestrictions
via the Azure portal.Workaround: Manually add the required
ipSecurityRestrictions
configuration through the Azure portal to enable public network access for the deployment.Impact: This issue prevents developers from deploying function apps directly from their IDEs when a private endpoint is configured, disrupting the development workflow.
Suggested Solution: Provide a mechanism to automatically add
ipSecurityRestrictions
in the module when the public network access is to be allowed for certain IPs via AVM.(Optional) Correlation Id
No response