GitHub
GitHub 是一项基于 Web 的软件开发托管服务,提供带有版本控制的代码存储和管理服务。您可以使用 Amazon Kendra 为 GitHub Enterprise Cloud(SaaS)和 GitHub Enterprise Server(本地部署)存储库文件、议题和拉取请求、议题和拉取请求评论以及议题和拉取请求评论附件编制索引。您也可以选择包括或排除某些文件。
注意
Amazon Kendra 现在支持升级后的 GitHub 连接器。
控制台已为您自动升级。您在控制台中新建的所有连接器都将使用升级后的架构。如果您使用 API,则现在必须使用 TemplateConfiguration 对象而不是 GitHubConfiguration 对象来配置您的连接器。
使用旧版控制台或旧版 API 架构配置的连接器仍可照常运行,但您将无法编辑或更新它们。如果要编辑或更新连接器配置,必须新建一个连接器。
我们建议您将连接器工作流程迁移至升级后的版本。使用旧版架构配置的连接器的支持预计将在 2024 年 6 月前终止。
您可以使用 Amazon Kendra 控制台
要对 Amazon Kendra GitHub 数据来源连接器进行故障排除,请参阅。
支持的功能
Amazon Kendra GitHub 数据来源连接器支持以下功能:
-
字段映射
-
用户访问控制
-
包含/排除筛选条件
-
完整和增量内容同步
-
虚拟私有云(VPC)
先决条件
在使用 Amazon Kendra 为 GitHub 数据来源编制索引之前,请先在 GitHub 和 AWS 账户内进行这些更改。
在 GitHub 中,请确保:
-
创建了一个拥有 GitHub 组织管理权限的 GitHub 用户。
-
已在 GitHub 中配置了个人访问令牌,用作您的身份验证凭证。请参阅有关创建个人访问令牌的 GitHub 文档
。 注意
我们建议您定期刷新或轮换您的凭证和密码。为了安全起见,请仅提供必要的访问权限级别。我们建议不要跨数据来源以及连接器版本 1.0 和 2.0(如果适用)重复使用凭证和密钥。
-
推荐:为身份验证凭证配置了 OAuth 令牌。使用 OAuth 令牌可获得更好的 API 限制和连接器性能。请参阅有关 OAuth 身份验证的 GitHub 文档
。 -
已记下您使用的 GitHub 服务类型的 GitHub 主机 URL。例如,GitHub 云的主机 URL 可能是
https://api.github.com,GitHub 服务器的主机 URL 可能是https://on-prem-host-url/api/v3/。 -
已记下您的 GitHub 组织名称、您要连接的 GitHub 企业云(SaaS)账户或 GitHub 企业服务器(本地)账户。您可以登录 GitHub 桌面并在个人资料图片下拉列表下方选择您的组织来找到您的组织名称。
-
可选(仅限服务器):生成 SSL 证书并复制存储在 Amazon S3 存储桶中的证书的路径。如果您需要安全的 SSL 连接,则可以使用它来连接 GitHub。您只需使用 OpenSSL 在任何计算机上生成自签名 X509 证书。有关使用 OpenSSL 创建 X509 证书的示例,请参阅创建并签署 X509 证书。
-
添加了以下权限:
适用于 GitHub 企业云(SaaS)
-
repo:status– 授予公有和私有存储库中的提交状态的读/写权限。只有在向其他用户或服务授予访问私有存储库提交状态的权限,但不授予访问代码的权限时,才需要使用此范围。 -
repo_deployment– 授予访问公有和私有存储库的部署状态的权限。只有在向其他用户或服务授予访问部署状态的权限,但不授予访问代码的权限时,才需要使用此范围。 -
public_repo– 限制对公有存储库的访问。这包括对公有存储库的代码、提交状态、存储库项目、协作者和部署状态以及对组织的读/写权限。此外还需要为公有存储库添加星标。 -
repo:invite– 授予接受/拒绝在存储库上开展协作的邀请的能力。只有在向其他用户或服务授予使用邀请的权限,但不授予访问代码的权限时,才需要使用此范围。 -
security_events– 授权:在代码扫描 API 中读取和写入安全事件的权限。只有在向其他用户或服务授予访问安全事件的权限,但不授予访问代码的权限时,才需要使用此范围。 -
read:org– 对组织成员资格、组织项目和团队成员资格的只读访问权限。 -
user:email– 授予对用户电子邮件地址的读取访问权限。Amazon Kendra 爬取 ACL 所必需。 -
user:follow– 授予关注或取消关注其他用户的权限。Amazon Kendra 爬取 ACL 所必需。 -
read:user– 授予读取用户个人资料数据的访问权限。Amazon Kendra 爬取 ACL 所必需。 -
workflow– 授予添加和更新 GitHub 操作工作流程文件的能力。如果同一存储库中的另一个分支上存在相同的文件(路径和内容均相同),则可以在没有此范围的情况下提交工作流文件。
有关更多信息,请参阅 GitHub 文档中的 Scopes for OAuth apps
。 适用于 GitHub 企业服务器(本地部署)
-
repo:status– 授予公有和私有存储库中的提交状态的读/写权限。只有在向其他用户或服务授予访问私有存储库提交状态的权限,但不授予访问代码的权限时,才需要使用此范围。 -
repo_deployment– 授予访问公有和私有存储库的部署状态的权限。只有在向其他用户或服务授予访问部署状态的权限,但不授予访问代码的权限时,才需要使用此范围。 -
public_repo– 限制对公有存储库的访问。这包括对公有存储库的代码、提交状态、存储库项目、协作者和部署状态以及对组织的读/写权限。此外还需要为公有存储库添加星标。 -
repo:invite– 授予接受/拒绝在存储库上开展协作的邀请的能力。只有在向其他用户或服务授予使用邀请的权限,但不授予访问代码的权限时,才需要使用此范围。 -
security_events– 授权:在代码扫描 API 中读取和写入安全事件的权限。只有在向其他用户或服务授予访问安全事件的权限,但不授予访问代码的权限时,才需要使用此范围。 -
read:user– 授予读取用户个人资料数据的访问权限。Amazon Q 企业版爬取 ACL 所必需。 -
user:email– 授予对用户电子邮件地址的读取访问权限。Amazon Q 企业版爬取 ACL 所必需。 -
user:follow– 授予关注或取消关注其他用户的权限。Amazon Q 企业版爬取 ACL 所必需。 -
site_admin– 授予站点管理员访问 GitHub Enterprise Server 管理 API 端点的权限。 -
workflow– 授予添加和更新 GitHub 操作工作流程文件的能力。如果同一存储库中的另一个分支上存在相同的文件(路径和内容均相同),则可以在没有此范围的情况下提交工作流文件。
有关更多信息,请参阅《GitHub Docs》中的 Scopes for OAuth apps
,以及《GitHub Developer》中的 Understanding scopes for OAuth Apps 。 -
-
在 GitHub 以及计划用于编制同一索引的其他数据来源中,已检查每个文档都是唯一的。您要用于编制索引的每个数据来源在所有数据来源中都不能包含相同的文档。文档 ID 对索引来说是全局性的,并且每个索引都必须是唯一的。
在 AWS 账户 中,请确保:
-
已创建 Amazon Kendra 索引,如果使用 API,则记下索引 ID。
-
为您的数据来源创建了一个 IAM 角色,如果使用 API,请记下 IAM 角色的 ARN。
注意
如果您更改了身份验证类型和证书,则必须更新您的 IAM 角色才能访问正确的 AWS Secrets Manager 密钥 ID。
-
将您的 GitHub 身份验证凭证存储在 AWS Secrets Manager 密钥中,如果使用 API,请记下密钥的 ARN。
注意
我们建议您定期刷新或轮换您的凭证和密码。为了安全起见,请仅提供必要的访问权限级别。我们建议不要跨数据来源以及连接器版本 1.0 和 2.0(如果适用)重复使用凭证和密钥。
如果您没有现有的 IAM 角色或密钥,则在将 GitHub 数据来源连接到 Amazon Kendra 时,您可以使用控制台创建新的 IAM 角色和 Secrets Manager 密钥。如果您使用 API,则必须提供现有 IAM 角色和 Secrets Manager 密钥的 ARN 以及索引 ID。
连接说明
要将 Amazon Kendra 连接到 GitHub 数据来源,您必须提供 GitHub 数据来源的必要详细信息,这样 Amazon Kendra 才能访问您的数据。如果您还没有为 Amazon Kendra 配置 GitHub,请参阅先决条件。
了解更多
要了解有关将 Amazon Kendra 与 GitHub 数据来源集成的更多信息,请参阅: