Codespaces accessing Azure resources

[MSFTJim]

Select Topic Area

Product Feedback

Body

Codespaces uses its internal private IP when connecting to Azure storage
Note: It does not appear to do this when connecting to Azure DB - it uses its public IP

In storage, if I setup firewall rules, using the public IP of the Codespace doesn’t work because its uses its private IP, so I am left to set 'Allow all public access'

Can we get some UI support to let us configure Service or Private Endpoints?

Or, an additional consideration…..
SQL has an exception rule that allow connections from IP addresses allocated to any Azure service. This allows connections from Codespaces.

[github-actions[bot]]

💬 Your Product Feedback Has Been Submitted 🎉

Thank you for taking the time to share your insights with us! Your feedback is invaluable as we build a better GitHub experience for all our users.

Here's what you can expect moving forward ⏩

• Your input will be carefully reviewed and cataloged by members of our product teams. 
  • Due to the high volume of submissions, we may not always be able to provide individual responses.
  • Rest assured, your feedback will help chart our course for product improvements.
• Other users may engage with your post, sharing their own perspectives or experiences. 
• GitHub staff may reach out for further clarification or insight. 
  • We may 'Answer' your discussion if there is a current solution, workaround, or roadmap/changelog post related to the feedback.

Where to look to see what's shipping 👀

• Read the Changelog for real-time updates on the latest GitHub features, enhancements, and calls for feedback.
• Explore our Product Roadmap, which details upcoming major releases and initiatives.

What you can do in the meantime 💻

• Upvote and comment on other user feedback Discussions that resonate with you.
• Add more information at any point! Useful details include: use cases, relevant labels, desired outcomes, and any accompanying screenshots.

As a member of the GitHub community, your participation is essential. While we can't promise that every suggestion will be implemented, we want to emphasize that your feedback is instrumental in guiding our decisions and priorities.

Thank you once again for your contribution to making GitHub even better! We're grateful for your ongoing support and collaboration in shaping the future of our platform. ⭐

[timrobertsusa]

I am having same issues when connecting from Codespaces to Azure Blob storage. We have used Kusto to validate the connection success and failures. DBAS, DBAF.

[ManuGS2]

having same issue. Used to work in the past when whitelisting public IP, but since a while ago it stopped working and start using the private IP from the codespace

[a-ariff]

GitHub Codespaces and Azure Storage Firewall: A Comprehensive Solution Guide

Great question! This is indeed a common challenge when working with GitHub Codespaces and Azure resources. Let me provide a comprehensive analysis and practical solutions.

🔍 Understanding the Problem

The core issue stems from how GitHub Codespaces handles network connectivity:

1. Private vs Public IP Usage in Codespaces

GitHub Codespaces Network Architecture:

• Private IP Range: Codespaces operate within GitHub's internal network using private IP addresses (typically in the 172.16.0.0/12 range)
• Public IP Behavior: While Codespaces do have public IP addresses for general internet access, Azure services often see connections originating from GitHub's internal infrastructure
• Inconsistent Behavior: As you've noticed, different Azure services (like Azure SQL vs Storage) may see different source IPs due to how the network routing is handled

2. Azure Storage Firewall Rules and VNET Integration

How Azure Storage Firewall Works:

# Azure Storage firewall operates at the service level
# It checks the source IP of incoming requests
# Rules: Allow specific IPs/ranges, VNET subnets, or trusted services

Current Limitations:

• Standard firewall IP rules don't work reliably with Codespaces
• VNET integration isn't directly available for Codespaces
• "Allow Azure services" doesn't include GitHub Codespaces by default

💡 Practical Solutions and Workarounds

Solution 1: Private Endpoints for Codespaces (Recommended)

While GitHub doesn't natively support private endpoints for Codespaces, you can implement a hybrid approach:

# Create a Private Endpoint for your storage account
az network private-endpoint create \
    --resource-group myResourceGroup \
    --name myStoragePrivateEndpoint \
    --vnet-name myVNet \
    --subnet mySubnet \
    --private-connection-resource-id /subscriptions/xxx/resourceGroups/xxx/providers/Microsoft.Storage/storageAccounts/mystorageaccount \
    --connection-name myConnection \
    --group-ids blob

# Configure Private DNS Zone
az network private-dns zone create \
    --resource-group myResourceGroup \
    --name "privatelink.blob.core.windows.net"

az network private-dns link vnet create \
    --resource-group myResourceGroup \
    --zone-name "privatelink.blob.core.windows.net" \
    --name myDNSLink \
    --virtual-network myVNet \
    --registration-enabled false

Codespaces Integration:

# In your Codespace, use Azure CLI to authenticate
az login --use-device-code

# Access storage through the private endpoint URL
# Instead of: mystorageaccount.blob.core.windows.net
# Use: mystorageaccount.privatelink.blob.core.windows.net

Solution 2: Service Tags and NAT Gateway

Using Azure Service Tags:

# Allow GitHub service tag in your NSG rules
az network nsg rule create \
    --resource-group myResourceGroup \
    --nsg-name myNetworkSecurityGroup \
    --name AllowGitHub \
    --protocol Tcp \
    --priority 100 \
    --source-address-prefix "GitHub" \
    --source-port-range '*' \
    --destination-address-prefix '*' \
    --destination-port-range '443'

NAT Gateway Approach:

# Create a NAT Gateway for consistent outbound IP
az network nat gateway create \
    --resource-group myResourceGroup \
    --name myNATGateway \
    --public-ip-addresses myPublicIP \
    --idle-timeout 10

# Associate with subnet
az network vnet subnet update \
    --resource-group myResourceGroup \
    --vnet-name myVNet \
    --name mySubnet \
    --nat-gateway myNATGateway

Solution 3: Azure Storage - Trusted Services Configuration

# Enable trusted Microsoft services exception
az storage account update \
    --resource-group myResourceGroup \
    --name mystorageaccount \
    --bypass AzureServices \
    --default-action Deny

# Add specific service endpoints
az storage account network-rule add \
    --resource-group myResourceGroup \
    --account-name mystorageaccount \
    --action Allow \
    --service "Microsoft.Compute"

Solution 4: Application-Level Authentication (Most Secure)

Using Managed Identity with Azure CLI:

# In your Codespace devcontainer.json
{
    "features": {
        "ghcr.io/azure/azure-dev/azd:latest": {},
        "ghcr.io/devcontainers/features/azure-cli:1": {}
    },
    "postCreateCommand": "az extension add --name storage-preview"
}

Python Example with DefaultAzureCredential:

from azure.identity import DefaultAzureCredential
from azure.storage.blob import BlobServiceClient

# This works regardless of IP restrictions
default_credential = DefaultAzureCredential()

blob_service_client = BlobServiceClient(
    account_url="https://mystorageaccount.blob.core.windows.net",
    credential=default_credential
)

# Access blobs without IP restrictions
container_client = blob_service_client.get_container_client("mycontainer")
blobs = container_client.list_blobs()

PowerShell Example:

# Connect using Azure PowerShell in Codespace
Connect-AzAccount -UseDeviceAuthentication

# Access storage with context authentication
$ctx = (Get-AzStorageAccount -ResourceGroupName "myRG" -Name "mystorageaccount").Context
$blobs = Get-AzStorageBlob -Container "mycontainer" -Context $ctx

🛠️ ARM Template for Complete Solution

{
    "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
    "contentVersion": "1.0.0.0",
    "parameters": {
        "storageAccountName": {
            "type": "string",
            "metadata": {
                "description": "Storage account name"
            }
        }
    },
    "resources": [
        {
            "type": "Microsoft.Storage/storageAccounts",
            "apiVersion": "2021-09-01",
            "name": "[parameters('storageAccountName')]",
            "location": "[resourceGroup().location]",
            "sku": {
                "name": "Standard_LRS"
            },
            "kind": "StorageV2",
            "properties": {
                "networkAcls": {
                    "bypass": "AzureServices",
                    "virtualNetworkRules": [],
                    "ipRules": [],
                    "defaultAction": "Allow"
                },
                "supportsHttpsTrafficOnly": true,
                "encryption": {
                    "services": {
                        "blob": {
                            "keyType": "Account",
                            "enabled": true
                        }
                    },
                    "keySource": "Microsoft.Storage"
                },
                "allowBlobPublicAccess": false
            }
        }
    ]
}

🔧 Troubleshooting Guide

1. Diagnose IP Issues:

# Check your current public IP in Codespace
curl -s https://ipinfo.io/ip

# Test Azure Storage connectivity
az storage blob list --account-name mystorageaccount --container-name mycontainer --auth-mode login

# Check if using private IP (internal GitHub network)
ip addr show | grep inet

2. Common Error Messages:

"This request is not authorized to perform this operation using this permission"

# Solution: Use proper authentication
az login --scope https://storage.azure.com/.default

"The request may be blocked by network rules"

# Solution: Check firewall settings
az storage account show --resource-group myRG --name mystorageaccount --query networkRuleSet

3. Network Debugging:

# Test connectivity to storage endpoint
nslookup mystorageaccount.blob.core.windows.net
ping mystorageaccount.blob.core.windows.net

# Check routing table
route -n

# Trace network path
traceroute mystorageaccount.blob.core.windows.net

🏆 Best Practices for Secure Access

1. Defense in Depth:

• Use Azure AD authentication instead of relying solely on IP restrictions
• Implement RBAC (Role-Based Access Control)
• Enable storage account logging and monitoring

2. Codespace Configuration:

// .devcontainer/devcontainer.json
{
    "name": "Azure Development",
    "image": "mcr.microsoft.com/devcontainers/universal:2-linux",
    "features": {
        "ghcr.io/devcontainers/features/azure-cli:1": {},
        "ghcr.io/devcontainers/features/docker-in-docker:2": {}
    },
    "postCreateCommand": [
        "az extension add --name storage-preview",
        "az config set core.allow_broker=true"
    ],
    "remoteEnv": {
        "AZURE_CLIENT_ID": "${localEnv:AZURE_CLIENT_ID}",
        "AZURE_CLIENT_SECRET": "${localEnv:AZURE_CLIENT_SECRET}",
        "AZURE_TENANT_ID": "${localEnv:AZURE_TENANT_ID}"
    }
}

3. Environment-Specific Solutions:

# Development Environment
az storage account update --name dev-storage --default-action Allow

# Production Environment  
az storage account update --name prod-storage --default-action Deny
az storage account network-rule add --account-name prod-storage --service Microsoft.KeyVault

📋 Summary

The recommended approach for GitHub Codespaces + Azure Storage is:

1. Short-term: Use Azure AD authentication with "Allow Azure Services" enabled
2. Medium-term: Implement application-level authentication using DefaultAzureCredential
3. Long-term: Advocate for GitHub to provide dedicated service tags or VNET integration options

This hybrid approach provides both security and functionality while working within current limitations.

Key Takeaway: Don't rely solely on IP-based restrictions for Codespaces. Instead, use Azure AD authentication combined with proper RBAC for robust, scalable security.

Hope this helps! Let me know if you need clarification on any of these solutions. 🚀