Accessing Resources

Resources that are connected to the TAMU-managed network will not be directly accessible from the internet, so you will need to use one of the approved access methods to connect to your resources. For administrative access to virtual machines specifically, a shared Azure Bastion service is provided in the hub VNet and is available to all spokes by default.

Access Methods

These access methods will vary based on the type of resource and the connectivity options it supports, but may include:

• Campus Network: You can connect to most resources securely on their private IP addresses from the campus network or via the Campus VPN service.
• Azure Front Door: For web applications or static web content that need to be accessible from the internet, Azure Front Door can be used to provide secure, global access with features like SSL termination, Web Application Firewall, and DDoS protection. This is the recommended access method for public web content.
• Azure Firewall: For other types of resources that need to be accessible from the internet, Azure Firewall can be used to provide secure access while still allowing for inspection and control of traffic.
• Azure Bastion: For administrative access (RDP/SSH) to virtual machines, the shared hub-managed Azure Bastion service provides secure, browser-based connectivity without requiring public IPs on your VMs or a VPN connection.

Private Link, Private Endpoints, and Private DNS

Private Link and Private Endpoints allow you to access a resource over a private IP address within your virtual network, rather than over the public internet, and enable many of the access methods described below. Private DNS is an important part of ensure this service works as expected.

See the Private Endpoints & DNS documentation for more information on how Private DNS is used to enable private network access to services via Private Link and Private Endpoints.

Campus Network Access

The TAMU managed network in Azure is connected to the campus network by a private, high-speed connection, so you can access your resources securely on their private IP addresses from the campus network or via the Campus VPN service. This is the current recommended access method for most resources, as it provides secure, private connectivity without exposing your resources to the public internet.

You will need to create security group rules to allow this traffic, since all inbound traffic is blocked by default. Best practice is to create rules that follow the principle of least privilege, allowing only the necessary traffic from the campus network to your resources.

To allow all traffic from the campus network and other trusted networks, you can create a rule with the following properties:

Important

This rule allows all traffic from the campus network and other trusted networks, so it should be used with caution and only if you have other controls in place to protect your resources, such as encryption, strong authentication, and monitoring. It is recommended to create more specific rules that only allow the necessary traffic to your resources.

Azure Front Door

If your resource is a web application, static web content, or other HTTP/S-based service that needs to be accessible from the internet, Cloud Services operates a shared instance of Azure Front Door that can be used to provide secure, global access with features like SSL termination, Web Application Firewall, and DDoS protection. This is the recommended access method for public web content.

Use the Services Configuration guide to set up your origin service, such as App Service, App Gateway, or internal Load Balancer, then contact the Cloud Services team to configure Azure Front Door.

Azure Front Door will create a managed private endpoint for your origin service using Private Link, which must be accepted by you in your origin configuration before traffic can flow from Azure Front Door to your origin service.

See the Supported Origins for Azure Front Door Private Link for more information on which types of origin services can be used with Azure Front Door and Private Link and how to accept the private link connection request for your origin services.

Azure Firewall

For other types of resources that need to be accessible from the internet, Azure Firewall can be used to provide secure access while still allowing for inspection and control of traffic. This is typically used for non-web workloads that still require some level of public accessibility. Use the Services Configuration guide to set up your resource then contact the Cloud Services team to configure Azure Firewall for secure access.

Warning

Administrative protocols, such as RDP, SSH, or any protocols without TLS encryption, will not be opened to the internet through Azure Firewall. For administrative access to virtual machines, use the shared hub Azure Bastion service (see Azure Bastion below). For other administrative access, use the campus network or VPN. If you have a specific use case that requires administrative access from the internet, please contact the Cloud Services team to discuss your requirements and potential solutions.

CI/CD Access

Some customers use CI/CD workflows or other automation to deploy Azure resources by sending requests to Azure Resource Manager (ARM). ARM is the Azure control plane API and is reachable from the internet, so a pipeline running in GitHub Actions (or any internet-connected runner) can create, update, or delete resources in your subscription without private network access.

However, if your CI/CD workflow needs to connect to resources in your VNet (for example, to publish or test a web application to a private App Service, or to access a private database), you will a connection path into the TAMU managed network, or data plane.

GitHub Actions

For customers using GitHub, GitHub Actions can be configured to access your TAMU managed network spoke VNet through a private endpoint. This allows GitHub to securely access external resources, such as package registries and other services, while keeping the GitHub instance itself isolated from direct internet access. The GitHub “Organization” and your target VNet will need one-time configuration for this with assistance from Cloud Services, and your workflow action yml(s) will need to be updated accordingly.

Configure Your VNet

GitHub requires a dedicated, delegated subnet in your VNet to connect securely. The minimum size for this subnet is /29, which provides 6 usable IP addresses for GitHub runners. Size this subnet according to your anticipated usage, as each concurrent workflow job will require an IP address for the runner. See GitHub documentation on determining subnet size.

You will also need to know the databaseId for your GitHub organization. The most common TAMU GitHub Organizations are listed below.

Follow the GitHub instructions to obtain the database ID for your organization if it is not listed here.

GitHub provides a script to configure your VNet and the necessary Azure resources for this connection. Contact Cloud Services to run this script if you do not feel confident doing this yourself, or if you have any questions about the configuration.

Configure GitHub

Once your VNet is configured, contact the GitHub team to complete the setup work in the GitHub organization. Include the following information in your request:

• Your target subscription, VNet, and subnet names
• The GitHub repositories that should be granted access

Update GitHub Workflows

Once your GitHub repository has been configured for private subnet access, you will need to update your workflow YAML files to use the new runner group created by the GitHub team for your VNet.

jobs:
  build:
    runs-on:
      group: <runner-group-name> # Provided by GitHub team
      labels: <standard runner labels, e.g. `ubuntu-latest`>
    steps:
      - name: Checkout code
        uses: actions/checkout@v2
      - name: Build and deploy
        run: |
          # Your build and deployment commands here

Other CI/CD Platforms

If you are using a different CI/CD platform, such as Azure DevOps, Jenkins, or CircleCI, you can still connect to your VNet securely using a similar approach with a private endpoint. Consult the documentation for your platform or Cloud Services for assistance with configuring your VNet and CI/CD platform for this connectivity.

Azure Bastion

For administrative access (RDP/SSH) to virtual machines in your spoke VNet, Cloud Services operates a shared Azure Bastion instance in the hub VNet. This is the approved method for administrative access to VMs and removes the need to assign public IPs to VMs or rely solely on the campus VPN.

Because spoke VNets are peered to the hub, the shared Bastion is automatically available to any VM in your spoke. When you open a VM in the Azure portal and select Connect → Bastion, the hub Bastion will appear as the connection option — no per-spoke Bastion deployment, AzureBastionSubnet, or additional peering configuration is required.

Requirements

• The VM must be in a spoke VNet peered to the hub (the default for managed spokes).
• Your account must have at least Reader role on the VM, its NIC, and the hub Bastion resource. Contact Cloud Services if the Bastion option does not appear when attempting to connect.
• The VM’s NSG must allow inbound RDP (3389) and/or SSH (22) from the hub AzureBastionSubnet range.
• VMs should not have public IP addresses assigned for administrative access.

Connecting

1. Navigate to your VM in the Azure portal.
2. Select Connect, then choose the Bastion tab.
3. The shared hub Bastion will appear automatically.
4. Enter your VM credentials and select Connect to open a browser-based RDP/SSH session.

For native client (local RDP/SSH) access through Bastion tunneling, see Connect using a native client. The hub Bastion name and resource group can be obtained from Cloud Services.

References

• What is Azure Bastion?
• Connect to a Windows VM using Bastion
• Connect to a Linux VM using Bastion
• Bastion and VNet peering