Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Modify NSG in hub Resource Group #443

Closed
Phydeauxman opened this issue Oct 7, 2021 · 1 comment · Fixed by #538
Closed

Modify NSG in hub Resource Group #443

Phydeauxman opened this issue Oct 7, 2021 · 1 comment · Fixed by #538
Assignees
Labels
bug Something isn't working

Comments

@Phydeauxman
Copy link
Contributor

Description

Currently, the hub NSG includes inbound rules for 22 and 3389 for remote access. Unsure whether these are created as part of the hub deployment when the NSG is created or added to the NSG when the remoteAccess example gets deployed into the hub. These rules are not needed when using Bastion and should be removed. Additionally, when the remoteAccess solution is deployed into the hub, the hub NSG is attached to the NIC of both the Windows and Linux VMs that get deployed. This is a duplicative assignment as the NSG is already attached to the subnet that the VMs get deployed into.

Steps to Reproduce

Steps to reproduce the behavior:

  1. Deploy MLZ instance using current code base
  2. Deploy remoteAccess solution using current code base

Expected behavior

Hub NSG is created with default inbound and outbound rule set. Hub NSG is assigned to hub-subnet subnet. Remote access VMs are deployed into hub-subnet and do not have the NSG applied directly to their NICs.

Actual behavior

Hub NSG gets created with inbound rules for 22 and 3389. When remoteAccess solution is deployed into hub Resource Group, the hub NSG gets assigned directly to the NICs of the Windows and Linux VMs.

Screenshots

None

Additional context

Operating System: NA
Terraform Version: NA
Cloud (public, Azure Government, etc.): All

@Phydeauxman Phydeauxman added bug Something isn't working needs triage labels Oct 7, 2021
@glennmusa
Copy link
Contributor

Specifically it looks like we can omit this opinion from hubNetwork.bicep and instead let the user cascade any custom NSG rule array they want to propogate:

var defaultNetworkSecurityGroupRules = [
{
name: 'allow_ssh'
properties: {
description: 'Allow SSH access from anywhere'
access: 'Allow'
priority: 100
protocol: 'Tcp'
direction: 'Inbound'
sourcePortRange: '*'
sourceAddressPrefix: '*'
destinationPortRange: '22'
destinationAddressPrefix: '*'
}
}
{
name: 'allow_rdp'
properties: {
description: 'Allow RDP access from anywhere'
access: 'Allow'
priority: 200
protocol: 'Tcp'
direction: 'Inbound'
sourcePortRange: '*'
sourceAddressPrefix: '*'
destinationPortRange: '3389'
destinationAddressPrefix: '*'
}
}
]

And remove this assignment in networkInterface.bicep since the created NIC will be grandfathered into whatever the subnet rules are (and Bastion doesn't need these to enable remote access):

networkSecurityGroup: {
id: networkSecurityGroupId
}

@vidyambala vidyambala self-assigned this Nov 9, 2021
vidyambala added a commit that referenced this issue Nov 19, 2021
* Modify NSG in hub Resource Group #443

* GitHub Action: Build Bicep to JSON

Co-authored-by: github-actions <[email protected]>
jwaltireland pushed a commit to ARPA-H/AzureMissionLZ that referenced this issue Nov 14, 2024
…#538)

* Modify NSG in hub Resource Group Azure#443

* GitHub Action: Build Bicep to JSON

Co-authored-by: github-actions <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants