将 LDAP 配置为身份提供者

本文描述了如何配置 Tetrate Service Bridge(TSB)的 LDAP 集成。在 TSB 中,LDAP 集成允许你将 LDAP 用作用户登录 TSB 的身份提供者,并自动将用户和组从 LDAP 同步到 TSB。

本文假定你已经具备配置 LDAP 服务以及如何使用它进行身份验证的工作知识。

配置

LDAP 可以通过ManagementPlane CR 或 Helm 值进行配置。以下是一个使用 LDAP 作为 TSB 身份提供者的自定义资源 YAML 的示例。你需要编辑ManagementPlane CR 或 Helm 值,并配置相关部分。请参阅LDAPSettings了解更多详细信息。

以下各节将更详细地解释 YAML 文件的每个部分的含义。

spec:
  hub: <registry-location>
  organization: <organization-name>
  ...
  identityProvider:
    ldap:
      host: <ldap-hostname-or-ip>
      port: <ldap-port>
      search:
        baseDN: dc=tetrate,dc=io
      iam:
        matchDN: "cn=%s,ou=People,dc=tetrate,dc=io"
        matchFilter: "(&(objectClass=person)(uid=%s))"
      sync:
        usersFilter: "(objectClass=person)"
        groupsFilter: "(objectClass=groupOfUniqueNames)"
        membershipAttribute: uniqueMember

身份提供者配置

使用 LDAP 作为身份提供者有两种方法:

  • 使用直接绑定身份验证
  • 使用基于搜索的身份验证

使用直接绑定身份验证是首选的,因为性能更好,但它要求整个 LDAP 树中的用户 Distinguished Names(“DN"s)是统一的。如果情况不是这样,可以配置更灵活的基于搜索的身份验证,以根据预先配置的查询对用户进行身份验证。

这些方法不是互斥的。如果都配置了,将首先尝试直接绑定身份验证,如果无法验证用户,TSB 将回退到使用基于搜索的身份验证。

直接绑定身份验证

在 LDAP 中,身份验证是通过执行与 DN 的绑定操作来完成的。DN 预期是一个已配置密码的用户记录。绑定操作尝试将给定的 DN 和密码与现有记录匹配。如果绑定操作成功,则身份验证成功。

然而,DNs 通常以以下形式出现,例如uid=nacx,ou=People,dc=tetrate,dc=io。这种格式对于常规登录来说不太方便,因为不应该要求用户在登录表单中键入完整的 DN。直接绑定身份验证允许你配置一个用于匹配登录用户的模式,并将其用作 DN。

以下示例配置了直接绑定身份验证模式:

iam:
  matchdn: 'uid=%s,ou=People,dc=tetrate,dc=io'

在此示例中,登录时,模式中的%s将被提供的登录用户替换,生成的 DN 将用于绑定身份验证。

基于搜索的身份验证

如前所述,如果所有现有用户都可以与相同的 DN 模式匹配,直接绑定身份验证效果很好。然而,在某些情况下,用户可能会创建在 LDAP 树的不同部分(例如,每个用户可以在组织内特定部门的组内创建),这样就不可能有一个单一的模式来匹配所有用户。

在这种情况下,你可以在 LDAP 树上执行搜索,查找与给定用户名匹配的记录,然后尝试使用记录的 DN 进行绑定身份验证。

为了执行搜索,必须建立到 LDAP 服务器的连接。如果服务器未配置为匿名访问,可能需要凭据。有关更多详细信息,请参阅“凭据和证书”部分。

以下示例显示了如何配置基于搜索的身份验证:

search:
  baseDN: dc=tetrate,dc=io
iam:
  matchfilter: '(&(objectClass=person)(uid=%s))'

在此示例中,配置了一个搜索,以查找从dc=tetrate,dc=io开始的树(iam.matchFilter使用在search.baseDN中定义的查询)。将尝试匹配所有类型为person并且具有uid属性等于给定用户名的记录。与直接绑定身份验证类似,搜索模式期望有一个%s占位符,该占位符将由给定的用户名替换。

结合直接和搜索身份验证方法

可以结合两种身份验证方法,以配置更灵活的身份验证配置。当同时配置了这两种方法时,直接绑定身份验证将具有优先权,因为它不需要遍历 LDAP 树,因此更有效率。

同时使用两种身份验证策略的示例可能如下所示:

iam:
  matchdn: 'uid=%s,ou=People,dc=tetrate,dc=io'
  matchfilter: '(&(objectClass=person)(uid=%s))'

使用 Microsoft Active Directory

Microsoft Active Directory 以不同的方式实现了 LDAP 绑定身份验证。它不使用 LDAP 绑定操作的完整 DN,而是使用用户(应该是形式为:user@domain)。

由于这是在登录表单中可能配置的用户名,因此直接身份验证可以简单地配置如下:

iam:
  matchdn: '%s'

如果直接身份验证无法满足所有身份验证需求,可以使用以下筛选器配置 Active Directory 中的基于搜索的身份验证,该筛选器匹配标准的 AD 用户帐户标识方式:

iam:
  matchfilter: '(&(objectClass=user)(samAccountName

=%s))'

凭据和证书

某些操作需要对 LDAP 服务器运行特权查询,例如获取整个组和用户列表,或使用搜索对用户进行身份验证。在这些情况下,如果需要凭据,则必须在 Kubernetes Secret 中进行配置。

你可以使用 tctl install manifest management-plane-secrets 命令创建所需的凭据和证书,以连接到 LDAP 服务器。

tctl install manifest management-plane-secrets \
    --ldap-bind-dn <ldap-bind-dn> \
    --ldap-bind-password <ldap-bind-password> \
    --ldap-ca-certificate "$(cat ldap-ca.cert)" \
    --tsb-admin-password <tsb-admin-password> \
    --tsb-server-certificate "$(cat foo.cert)" \
    --tsb-server-key "$(cat foo.key)" > managementplane-secrets.yaml

如果无法使用上述命令并需要手动执行此操作,请按以下方式创建 ldap-credentials 密钥:

apiVersion: v1
kind: Secret
metadata:
  name: ldap-credentials
  namespace: tsb
data:
  binddn: 'base64-encoded full DN of the user to use to authenticate'
  bindpassword: 'base64-encoded password'

还需要创建 custom-host-ca 密钥,如果你的 LDAP 配置为使用自签名证书。

kubectl create secret generic custom-host-ca \
    --from-file=ca-certificates.crt=<path to custom CA file> \
    --namespace tsb

用户和组同步

用户和组的同步是通过运行上述 LDAP 配置中的同步查询来完成的。以下示例显示了可用于从标准 LDAP 服务器获取用户和组的两个示例查询。

membershipattribute 用于将用户与他们所属的组进行匹配。对于每个找到的组,将读取此属性以提取组的成员信息。

请注意,这些查询高度依赖于 LDAP 树结构,每个人都必须更改它们以进行匹配。

sync:
  usersfilter: '(objectClass=person)'
  groupsfilter: '(objectClass=groupOfUniqueNames)'
  membershipattribute: uniqueMember