Skip to main content
Skip to content

Предоставление GitHub Copilot облачным сеансам доступа к ресурсам в организации

Узнайте больше, Copilot предоставив ему доступ к утвержденным серверам MCP и внутренним пакетам в облачных сеансах.

Если вы включили Copilot in the cloud, необходимо настроить параметры организации, чтобы Copilot агенты могли подключаться к серверам MCP, использовать частные пакеты и получать доступ к внешним службам при автономной GitHubработе.

Некоторые из приведенных ниже конфигураций выполняются на уровне репозитория. Однако владельцы организации имеют контроль над тем, какие ресурсы находятся в области, и кто может настроить доступ к ним.

Сведения о средах сеансов

Сеансы GitHub агента могут выполняться в облачной песочнице или в GitHub Actionsней. Затраты на вычисления из обеих сред используют одинаковые ежемесячные пособия.

  • Облачная песочница — это более быстрая упрощенная среда, которая позволяет пользователям возобновлять сеансы в GitHubинтерфейсе чата или в других клиентах.
  • GitHub Actions обеспечивает больше контроля над средой, например секретами и переменными, этапами установки для установки зависимостей и доступом к локальным запускам или частным сетям.

Подробное сравнение см. в разделе GitHub Copilot на GitHub.com и GitHub Mobile.

В этом руководстве предполагается, что вы используете GitHub Actions в качестве вычислительной среды. В настоящее время облачные песочницы имеют меньше возможностей настройки доступа к ресурсам организации.

Пример сценария

Ваша организация использует Sentry для отслеживания багов в приложении Node. Новые исключения появляются как проблемы на GitHub, и ваши разработчики хотят назначить эти проблемы на Copilot.

Вы хотите Copilot :

  • Подключитесь к серверу Sentry MCP, чтобы он мог получить доступ к деталям вашего экземпляра Sentry
  • Устанавливайте зависимости, включая приватные пакеты, размещённые на GitHub, чтобы сформировать приложение и запускать тесты
  • Следуйте конвенциям вашей организации по устранению ошибок

Безопасное хранение секретов

По умолчанию Copilotобласть действия токена аутентификации ограничена репозиторием, в котором он выполняется. Это означает, что Copilot он не сможет аутентифицироваться во внешних системах или получить доступ к частным пакетам с организационным охватом.

Владельцы организации могут добавлять секреты агентов на уровне организации для совместного использования конфигурации в нескольких репозиториях. Copilot может получить доступ к этим данным во время настройки и выполнения задачи. Он не сможет получить доступ к секретам и переменным для GitHub Actions, Codespacesили Dependabot. Дополнительные сведения см. в разделе Настройте секреты и переменные для облачного агента Copilot.

Примечание.

Секреты для подключений к серверу MCP (префиксированные с COPILOT_MCP_) также будут доступны в облачных песочницах. Другие секреты агентов будут доступны только в GitHub Actions средах.

Пример: Сохранить секрет

Владелец организации сохраняет маркер проверки подлинности для экземпляра Sentry организации.

  1. Перейдите в раздел "Секреты и переменные > агенты" параметров организации.
  2. Сохраните токен доступа для вашего экземпляра Sentry в секрете под названием COPILOT_MCP_SENTRY_ACCESS_TOKEN.

Совет

Нам не нужно сохранять токен для приватного GitHub Packages реестра, к которому мы получим доступ через стандартный GitHub ActionsGITHUB_TOKEN. Однако, если вы используете внешний реестр пакетов, нужно сохранить токен аутентификации.

Настройка доступа к серверам MCP

Владельцы организаций и предприятий могут устанавливать политику, позволяющую пользователям настраивать доступ к серверам MCP. Если эта политика включена, пользователи могут настраивать MCP-серверы в Copilot настройках репозитория или в пользовательских профилях агентов. Для согласованности на уровне всей организации мы рекомендуем создавать индивидуальные профили агентов на уровне организации или предприятия.

Сессия с пользовательским агентом имеет доступ к MCP-серверам, настроенным как в настройках репозитория, так и в профиле агента. Однако чем больше случаев использования вы охватываете с пользовательскими агентами на уровне всей организации, тем меньше пользователям нужно будет настраивать ad hoc доступ к серверам MCP в настройках репозитория.

Вы также можете использовать файл предприятия managed-settings.json для создания списка разрешений утвержденных серверов MCP. См . раздел AUTOTITLE. allowedMcpServers и deniedMcpServers применяется к серверам MCP, определенным в параметрах пользователя и параметрах репозитория, но не применяются к серверам MCP, определенным в профилях пользовательского агента репозитория. Однако можно предотвратить использование серверов MCP, настроенных в профилях пользовательских агентов, гарантируя, что все необходимые домены для запуска не разрешены пользовательским брандмауэром на уровне организации или репозитория. См . раздел AUTOTITLE.

Рекомендуем просмотреть GitHub реестр MCP , чтобы найти надёжные и высокооценённые варианты.

Пример: Создать пользовательский агент

Владелец организации создаёт профиль индивидуального агента для агента Senti. Он имеет доступ к серверу Sentry MCP и пользовательским инструкциям для управления ошибками организации.

  1. Создайте репозиторий, который называется .github-private в вашей организации. Опционально, владелец предприятия может установить этот репозиторий в качестве исходного для всех пользовательских агентов в предприятии.

  2. В репозитории добавьте agent.md файл с профилем, подобным следующему. Это включает конфигурацию для сервера MCP, который ссылается на сохранённый нами секрет.

    ---
    name: sentry-error-fixer
    description: Proposed fixes for exception issues raised from Sentry
    mcp-servers:
      sentry:
        type: 'local'
        command: 'npx'
        args: ['@sentry/mcp-server@latest']
        env:
          SENTRY_ACCESS_TOKEN: ${{ secrets.COPILOT_MCP_SENTRY_ACCESS_TOKEN }}
    ---
    
    You are an error resolution specialist. When you're assigned an issue created by our Sentry integration, check for error details and stack traces using the MCP server, then propose a fix.
    
    Make sure you check that your proposed fix works by building the site with `npm run build` and running the test suite in `npm test`.
    
  3. Когда разработчики приписывают проблему к Copilot, они могут выбрать пользовательский агент из выпадающего меню.

Установка частных пакетов

Лучший способ дать Copilot доступ к зависимостям проекта — установить их в copilot-setup-steps.yml файл рабочего процесса. Этот файл определяет, как настроена среда до Copilot начала работы.

Чтобы рабочий процесс мог получать ваши приватные пакеты с организационным охватом, вы обновите настройки пакетов, чтобы убедиться, что репозитории GITHUB_TOKEN имеют доступ к пакету. Это безопаснее, чем использование долгоживущего personal access token с разрешениями организации.

Пример: зависимости от узлов установки

Разработчик создаёт рабочий процесс для установки зависимостей узлов, определённых в файле package-lock.json репозитория. Это включает частные, структурируемые пакеты, размещённые на GitHub.

  1. Разработчик создаёт copilot-setup-steps.yml файл в репозитории.

  2. Они добавляют шаги для установки зависимостей проекта. Рассмотрим пример.

    # ...
    
    jobs:
      copilot-setup-steps:
        # ...
    
        # You can define any steps you want, and they will run before the agent starts.
        # If you do not check out your code, Copilot will do this for you.
        steps:
          - name: Checkout code
            uses: actions/checkout@v6
    
          - name: Set up Node.js
            uses: actions/setup-node@v7
            with:
              node-version: "20"
              cache: "npm"
    
          - name: Install JavaScript dependencies
            run: npm ci
    
  3. Администратор организации гарантирует, что репозиторий имеет доступ к частным пакетам организации, предоставляя доступ к репозиторию в настройках каждого пакета. См . раздел AUTOTITLE.

Совет

Если вам нужно получить доступ к пакетам, размещенным внутри корпоративной сети, может потребоваться запустить Copilot агенты на локальных GitHub Actions запусках.

Управление тем, кто может настраивать эти настройки

Теперь, когда вы увидели, как контролируется доступ к ресурсам на уровне репозитория и организации, подумайте, сколько возможностей вы хотите предоставить пользователям для управления этими настройками.

  1. Выберите репозитории с доступом к Copilot in the cloud. Если вас беспокоит конкретный репозиторий, вы можете заблокировать его для всех пользователей.
  2. Подумайте, кто получает администраторский доступ к этим репозиториям. Вы можете контролировать это на уровне организации, создав команду с пользовательской ролью администратора всех репозиториев . Эти пользователи смогут управлять настройками конфигурации, такими как конфигурация MCP и секреты и переменные агентов, в каждом репозитории.
  3. Используйте наборы правил и файлы CODEOWNERS для управления редактированием конфигурационных файлов, таких copilot-setup-steps.ymlкак , которые по умолчанию может редактировать любой человек с правом записи.
  4. Проверьте стандартный межсетевой экран. Файрвол не влияет на подключение к серверам MCP или этапы настройки, copilot-setup-steps.ymlно ограничивает Copilotдоступ к Интернету во время выполнения задач. См . раздел AUTOTITLE.
  5. Определите стандарты подключаемого модуля. Плагины — это устанавливаемые пакеты, которые расширяются Copilot многоразовыми агентами, навыками, крючками и интеграциями. Вы можете контролировать, какие подключаемые модули и marketplace разрешены в файле предприятия managed-settings.json . См . раздел AUTOTITLE.