Critical changes coming to GitHub Actions: Ubuntu 24 migration guide

The looming change

On November 5, 2024, for detailed changes.

What this means for you

1. Immediate actions required

If you're using ubuntu-latest, you need to:

• 
  Audit Your Workflows: Before December 5, review every GitHub Actions workflow in your repositories.


• 
  Check Package Dependencies: Compare your required packages against the removal list.


• 
  Test on Ubuntu 24: Create a parallel workflow using ubuntu-24.04 to catch issues early.

2. Common pitfalls to watch for

• 
  Docker Build Times: Without cached images, expect longer build times.


• 
  Language Version Mismatches: Default versions are changing across the board.


• 
  Missing Development Tools: Many previously available tools will need manual installation.

3. Migration strategies

The Safe Approach

name: CI

on: [push]

jobs:

  build:

    runs-on: ubuntu-22.04  # Pin to 22.04 temporarily

    steps:

      - uses: actions/checkout@v4

      # Your existing steps

The forward-looking approach

name: CI

on: [push]

jobs:

  build:

    runs-on: ubuntu-latest

    steps:

      - uses: actions/checkout@v4

      # Explicitly install removed packages

      - name: Install required packages

        run: |

          sudo apt-get update

          sudo apt-get install -y terraform

      # Your existing steps

Critical changes for self-hosted runners

New domain and IP requirements

One of the most significant changes affects organizations using self-hosted runners. GitHub is implementing stricter security controls that require explicit domain and IP permissions.

What's changing?

1. Domain Allowlisting: Self-hosted runners will need explicit permissions to communicate with specific domains.




2. IP Range Restrictions: Organizations must configure allowed IP ranges for runner communications.




3. Network Security: Enhanced security measures for runner-to-GitHub communications.

Required actions for self-hosted runner administrators

1. Domain Configuration

# Example organization-level configuration

runner-security:

  allowed-domains:

    - "*.github.com"

    - "*.actions.githubusercontent.com"

    - Your custom domains needed for workflows

2. IP range configuration

You'll need to allowlist these IP ranges in your network security groups:

• GitHub Actions service IP ranges




• GitHub API endpoints




• GitHub package registry endpoints

3. Security Best Practices

# Example workflow with runner security configurations

name: Secure CI Pipeline

on: [push]

jobs:

  build:

    runs-on: self-hosted

    permissions:

      # Explicit permission definitions

      contents: read

      packages: read

    steps:

      - uses: actions/checkout@v4

      # Your workflow steps

Common pitfalls to avoid

1. Incomplete Domain Lists: Missing domains can break package downloads and external service integrations.




2. Over-permissive IP Ranges: Avoid using broad IP ranges; be specific to maintain security.




3. Missing Authentication Contexts: Ensure proper authentication for all external service communications.

Webhook rate limiting

GitHub is also introducing new rate limits for webhooks, which affects how frequently your self-hosted runners can receive job notifications:

• Default rate: X requests per hour (adjust based on actual numbers)




• Burst limit: Y requests per minute




• Cool-down period: Z minutes

Migration checklist for self-hosted runners

1. 
   

   Audit current configuration

   
   
   
   
   
   • Document all domains accessed by your workflows
   
   
   • List all required IP ranges
   
   
   • Review webhook usage patterns
   
   
   
   


2. 
   

   Update network configurations

   
   
   
   
   
   • Configure firewalls and security groups
   
   
   • Update proxy settings if applicable
   
   
   • Test connectivity with restricted permissions
   
   
   
   


3. 
   

   Monitor and validate

   
   
   
   
   
   • Set up monitoring for failed connections
   
   
   • Implement logging for security-related events
   
   
   • Create alerts for rate limit warnings
   
   
   
   


4. 
   

   Documentation updates

   
   
   
   
   
   • Update runner setup documentation
   
   
   • Document new security requirements
   
   
   • Create troubleshooting guides
   
   
   
   

Looking forward

This change signals a broader trend in CI/CD: the move toward more explicit dependency management. While it might seem inconvenient now, it's pushing us toward better practices:

1. 
   Explicit Over Implicit: Declaring all dependencies makes workflows more portable and maintainable.


2. 
   Container-First Thinking: Using container-based workflows reduces runner dependencies.


3. 
   Version Pinning: Being explicit about tool versions reduces "it works on my machine" issues.

Action items

1. Mark December 5, 2024, in your calendar.


2. Audit your GitHub Actions workflows this week.


3. Test your critical workflows on Ubuntu 24.


4. Update your dependencies management strategy.


5. Consider pinning to ubuntu-22.04 temporarily if you need more migration time.

Additional action items

1. Document all external service dependencies for self-hosted runners


2. Update network security policies


3. Configure webhook rate limit monitoring


4. Test runners with restricted permissions


5. Create a rollback plan for critical workflows

Security considerations

The new self-hosted runner requirements reflect GitHub's commitment to enhanced security. While these changes may require additional configuration, they provide:

• Better isolation between runners and external services


• Clearer audit trails for runner activities


• Reduced risk of unauthorized access


• Improved compliance with security standards

Remember: Security should never be an afterthought. These changes force us to be explicit about our security boundaries, which is ultimately a good thing for our CI/CD infrastructure.

The silver lining

While this change might seem disruptive, it's an opportunity to make our CI/CD workflows more robust. By forcing us to be explicit about our dependencies, GitHub is actually pushing us toward better DevOps practices.

Remember: The best time to prepare for this change was when it was announced. The second best time is now.

For more tips and insights, follow me on Twitter @Siddhant_K_code and stay updated with the latest & detailed tech content like this.