enterprise

Subscribe to all “enterprise” posts via RSS or follow GitHub Changelog on Twitter to stay updated on everything we ship.

→ ~ cd github-changelog
→ ~/github-changelog|main git log main
showing all changes successfully

[GA] Guest Collaborators for enterprise managed users

Guest Collaborators for GitHub Enterprise Cloud EMUs are now generally available. Originally announced in public beta at the end of last year, this feature allows an identity provider to assign the guest collaborator role to a user which will restrict that user’s default access to internal repositories.

Our thanks go to the thousands of public beta participants that guided our hand to the GA experience. By popular request, today we also released a public beta for repository collaborator access in EMU enterprises! This brings the “outside collaborator” access style to EMUs, limited to selecting users that are members of the enterprise account. Combining these two features together lets you grant the most granular possible access rights to specific repositories and organizations that fit your needs for contractors and other limited access use cases.

Learn more about guest collaborators

See more

[Public Beta] Repository collaborators for Enterprise Managed Users

Enterprise Managed Users can now be added directly to a repository in their enterprise as a collaborator, without becoming a member of the organization. These users function like outside collaborators, with a few differences:
1. Only user accounts from within the enterprise can be added to the repository. This means that users you want to collaborate with must still come from your linked identity provider (IDP).
2. EMU users can only be collaborators on repositories in their enterprise. EMU accounts cannot collaborate outside their enterprise.
3. Repo Collaborator invitations can only be sent by an EMU’s enterprise owner by default, while in non-EMU enterprises and organizations both enterprise and organization owners can manage outside collaborators.

Like outside collaborators – users do not have to SSO authorize their credentials in order to access repositories that they have been granted access to as a repository collaborators. This aligns to the current access model for internal repositories on GitHub.

You can try out repository collaborators by going to the repository policies section of your Enterprise settings and selecting which tiers of administrators are allowed to invite collaborators.

For more information about repository and outside collaborators, see “Roles in an organization“.

See more

Audit Log Streaming Health Check is Generally Available

GitHub’s audit log streaming health check is now generally available! The purpose of the audit log health check is to ensure audit log streams do not fail silently. Every 24 hours, a health check runs for each stream. If a stream is set up incorrectly, an email will be sent to the enterprise owners as notification that their audit log stream is not properly configured.

Example email notification for misconfigured stream

Streamed audit logs are stored for up to seven days on GitHub.com. To avoid audit log events being dropped from the stream, a misconfigured stream must be fixed within six days of email notification. To fix your streaming configuration, follow the steps outlined in “Setting up audit log streaming.”

See more

Enterprise Licensing page removing “Enterprise Help” section

GitHub Enterprise owners may notice that we removed the Enterprise Help links from your enterprise licensing page `https://github.com/enterprises//enterprise_licensing`, which were previously found here:

These shortcuts can still be found elsewhere:

  • GitHub Enterprise documentation is referenced underneath the README on the Enterprise Overview page `https://github.com/enterprises/`;
  • GitHub Support is discoverable both on the Enterprise Overview page as well as the Support page under settings `https://github.com/enterprises//settings/support`; and
  • GitHub Enterprise Server Support bundles can be uploaded from the Setup > Support Site Admin page as well as the GitHub Enterprise Cloud Support page under settings.
See more

GitHub Native IP Allow List expands to EMU User Namespaces – Private Beta

Enterprise owners of GitHub Enterprise Cloud with Enterprise Managed Users (EMUs) can now participate in a private beta introducing GitHub’s native IP allow list configuration to cover user namespaces. This feature will limit access to enterprise-managed user namespaces to the owning enterprise’s IP allow list. Access through the web UI, git protocol, and API are all filtered by the IP allow list. All credentials, including personal access tokens, app tokens, and SSH keys, are covered by this policy.

To enroll in this private beta and make this feature available for your enterprise, reach out to your GitHub Account Manager or contact our sales team.

See more

Updated GitHub App visibility for Enterprise Managed Users

We’ve clarified the GitHub App creation experience for Enterprise Managed Users (EMUs), updating it for both users and organizations that would like to create an app.

GitHub Apps created within an EMU enterprise are only accessible within the enterprise – they’re blocked for anyone else. In addition, EMU user accounts are unable to install GitHub applications.

To reflect this limitation, we’ve updated the creation UI to disable the “Private” option for EMU users, which prevents users from creating apps that no one can install. We’ve also updated the “Public” option to instead read “This enterprise”, more accurately reflecting where the app can actually be installed.

image

For more information about EMUs, see “About Enterprise Managed Users“. For more about GitHub Apps, see “About GitHub Apps“.

See more

SSH CA support for enterprise-owned user accounts

Enterprises that own their user accounts can now use SSH CAs to access user-owned repositories. This is an optional setting that enterprises can enable in their enterprise SSH CA settings page. Enabling this setting allows developers to use a single SSH certificate for all of their interactions with GitHub across their user account’s repositories and their enterprise’s repositories.

This is available now for customers using Enterprise Managed Users in GHEC, and will be included in GHES 3.14. It is not available to GHEC Classic enterprises, where developers bring their own personal accounts to the enterprise; the enterprise does not own those accounts and cannot gain access to their repositories.

For more about SSH certificate authorities, see “Managing SSH certificate authorities for your enterprise“.

See more

Actions Usage Metrics public beta

Customers desire clear, relevant, and actionable insights about how Actions workflows are being used in their organization. Today, we are thrilled to announce that Actions Usage Metrics is available in public beta for GitHub Enterprise Cloud plans.

Actions Usage Metrics screenshot

Time is the most important metric for DevOps and DevEx teams. The question they want answered is, “where are all my minutes going?” Actions Usage Metrics addresses this question and others by focusing on minutes used per workflow, job, repository, runtime OS, and runner type. This data helps organizations locate areas of improvement in their software delivery lifecycle, saving time and money.

Customers can filter data by any combination of workflows, jobs, repositories, runtime OS, and runner type to view total minutes, number of jobs, workflow executions, and more. All usage metrics, filtered or not, can be downloaded as a .csv file to use with your tool of choice.

By default, organization owners can access Actions Usage Metrics. However, access permissions can be granted to other members or teams using Actions fine-grained permissions. This ensures the right level of access to Actions Usage Metrics data, enabling informed decisions and improvements.

To learn more about Actions Usage Metrics, check out our docs or head to our community discussion.

See more

New SSH CAs must sign expiring certificates

SSH CAs uploaded to GitHub.com after March 27th, or in GHES 3.13 and beyond, can only sign certificates that expire. They must expire within 366 days of being created.
While expirations on certificates are not required by signing tools such as ssh-keygen, we are enforcing this best practice in order to protect against a weakness in how SSH certificates are linked to users.

CAs uploaded before the cutoff date or release will be marked in the UI as being allowed to sign non-expiring certificates:

image

An “upgrade” option on the CA lets you enforce expiration of signed certificates. Once you’ve validated that you are indeed using a lifetime on your certificates, we recommend upgrading your CAs. This upgrade step is irreversible, and new CAs cannot be downgraded to allow non-expiring certificates.
If a certificate is signed with no expiration, or a too-long expiration, it will be rejected during SSH connection with an error indicating The SSH certificate used was issued for a longer period than allowed.

This change forces the valid_after issuance timestamp to be written to the certificate, which allows GitHub to detect if the user changed their username after the certificate was issued for that username. This prevents a reuse attack vector where the former holder of a username is able to use certificates issued to them to sign in as the new holder of that username.

To learn more about managing SSH CAs, see “Managing your organization’s SSH CAs” and “Managing SSH CAs for your enterprise.” For information on using SSH CAs, see “About SSH CAs.”

See more

Logging SAML SSO and SCIM identity data in audit log events is generally available

Starting today for GitHub Enterprise Cloud and as part of GitHub Enterprise Server version 3.13, enterprise and organization audit log events will include the applicable SAML and SCIM identity data associated with the user. This data provides increased visibility into the identity of the user and enables logs from multiple systems to quickly and easily be linked using a common corporate identity. The SAML identity information will be displayed in the external_identity_nameid field and the SCIM identity data will be displayed in the external_identity_username field within the audit log payloads.

In GitHub Enterprise Cloud Classic, SAML SSO gives organization and enterprise owners a way to control and secure access to resources like repositories, issues, and pull requests. Organization owners can invite GitHub users to join an organization backed by SAML SSO, allowing users to become members of the organization while retaining their existing identity and contributions on GitHub.

If your Enterprise Cloud Classic organization uses SAML SSO, you can use SCIM to add, manage, and remove organization members’ access to your organization. For example, an administrator can deprovision an organization member using SCIM and automatically remove the member from the organization.

To learn more, read our documentation about SAML SSO authentication data in our audit logs.

See more

[Public Beta] Bring Your Own Identity Provider to Enterprise Managed Users

New customers of GHEC enterprise managed users (EMUs) can now use the SSO and SCIM providers of their choice, separate from one another, for a more flexible approach to user lifecycle management. EMU enterprises will allow all valid SAML 2.0 and SCIM implementations as part of this public beta.

We are progressively rolling out this change to existing enterprises through March 19th. Existing EMU enterprises will see a new opt-in capability to allow writes to the SCIM API for callers other than the partner identity applications currently supported. A personal access token (Classic) with the admin:enterprise scope is required for SCIM writes. While in public beta, we do not recommend that existing customers change their current production identity system.

opt into SCIM API writes

Learn more about provisioning enterprise managed users with the SCIM API. If you have questions about migrating identity providers, please review the updated documentation or contact your account team.

See more

The GitHub Enterprise Server 3.12 is generally available

GitHub Enterprise Server 3.12 is generally available

GitHub Enterprise Server 3.12 is now generally available and gives customers more fine-grained control over deployment requirements, as well as enhanced security controls. Here are a few highlights:

  • Restrict your deployment rollouts to select tag patterns in Actions Environments.
  • Enforce which Actions workflows must pass with organization-wide repository rulesets.
  • Scale your security strategy with Dependabot Alert Rules. This public beta allows customers to choose how to respond to Dependabot alerts automatically by setting up custom auto-triage rules in their repository or organization.
  • Automate pull request merges using Merge Queues. Previously developers needed to manually update their pull requests prior to merging, to ensure their changes wouldn’t break the main branch. These updates would initiate a round of continuous integration checks that needed to pass before a pull request could be merged. But with merge queues, this process is automated by ensuring each pull request queued for merging is tested with other pull requests queued ahead of it.
  • Enhance the security of your code with a public beta of Secret Scanning for non-provider patterns, and an update to Code Scanning’s default setup to support all CodeQL languages.
  • GitHub Project templates are available at the organization level, allowing customers to share out and learn best practices in how to set up and use projects to plan and track their work.
  • Updated global navigation to make using and finding information better, as well as improve accessibility and performance.
  • Highlight text in markdown files with accessibility aspects in mind with the alerts markdown extension, which gives you five levels to use (note, tip, important, warning, and caution).

Read more about GitHub Enterprise Server 3.12 in the release notes,
or download it now.
If you have any feedback or questions, please contact our Support team.

See more

Enterprise READMEs

Enterprise accounts now have a new root navigational experience, landing all users on an Enterprise Overview. Within this new page, GitHub Enterprise owners can create a README for their enterprise, which will be visible internally to all enterprise members. The Organization page still exists and can be found within the left-hand navigation of the enterprise account. This new experience is available on GitHub.com today and will be included in GitHub Enterprise Server 3.13.

To learn more, read our documentation on creating a README for an enterprise. To provide feedback about what you’d like to see on this new page, you may do so at anytime by clicking Give Feedback on the right-hand side of the new overview page, above the README.

See more

Secret scanning supports user namespace repositories for Enterprise Managed Users

Enterprise Managed Users can now enable secret scanning on their user namespace repositories. Owners of user repositories will receive secret scanning alerts when a supported secret is detected in their repository. User namespace repositories can also enable push protection.

In the enterprise level list of secret scanning alerts, enterprise owners can view all secrets detected in user namespace repositories. Enterprise owners can temporarily access user namespace repositories to view the secret details.

User namespace repositories are included in the security risk and coverage pages.

Secret scanning will also be supported on Enterprise Server personal repositories starting on GHES 3.13.

See more

The GitHub Enterprise Server 3.12 Release Candidate is available

The GitHub Enterprise Server 3.12 release candidate is here

GitHub Enterprise Server 3.12 gives customers more fine-grained control over deployment requirements, enhanced security controls, and some . Here are a few highlights:

  • Restrict your deployment rollouts to select tag patterns in Actions Environments.
  • Enforce which Actions workflows must pass with organization-wide repository rulesets.
  • Scale your security strategy with Dependabot Alert Rules. This public beta allows customers to choose how to respond to Dependabot alerts automatically by setting up custom auto-triage rules in their repository or organization.
  • Automate pull request merges using Merge Queues. Previously developers needed to manually update their pull requests prior to merging, to ensure their changes wouldn’t break the main branch. These updates would initiate a round of continuous integration checks that needed to pass before a pull request could be merged. But with merge queues, this process is automated by ensuring each pull request queued for merging is tested with other pull requests queued ahead of it.
  • Enhance the security of your code with a public beta of Secret Scanning for non-provider patterns, and an update to Code Scanning’s default setup to support all CodeQL languages.
  • GitHub Project templates are available at the organization level, allowing customers to share out and learn best practices in how to set up and use projects to plan and track their work.
  • Updated global navigation to make using and finding information better, as well as improve accessibility and performance.
  • Highlight text in markdown files with accessibility aspects in mind with the alerts markdown extension, which gives you five levels to use (note, tip, important, warning, and caution).

Release Candidates are a way for you to try the latest features early, and they help us gather feedback to
ensure the release works in your environment. They should be tested on non-production environments.
Read more about the release candidate process.

Read more about GitHub Enterprise Server 3.12 in the release notes,
or download the release candidate now.
If you have any feedback or questions, please contact our Support team.

See more
View more changes