forked from pivotal-cf/docs-pks
-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy path_uaa.html.md.erb
113 lines (86 loc) · 7.5 KB
/
_uaa.html.md.erb
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
To configure the UAA server, do the following:
1. Click **UAA**.
1. Under **PKS CLI Access Token Lifetime**, enter a time in seconds for the PKS CLI access token lifetime.<br>
<img src="images/uaa.png" alt="UAA pane configuration" width="325">
1. Under **PKS CLI Refresh Token Lifetime**, enter a time in seconds for the PKS CLI refresh token lifetime.
1. Select one of the following options:
* To use an internal user account store for UAA, select **Internal UAA**. Click **Save** and continue to [(Optional) Monitoring](#monitoring).
* To use an external user account store for UAA, select **LDAP Server** and continue to [Configure LDAP as an Identity Provider](#configure-ldap).
<p class="note"><strong>Note</strong>: Selecting <strong>LDAP Server</strong> allows admin users to give cluster access to groups of users. For more information about performing this procedure, see <a href="manage-users.html#cluster-access-group">Grant Cluster Access to a Group</a> in <em>Managing Users in PKS with UAA</em>.</p>
#### <a id="configure-ldap"></a>Configure LDAP as an Identity Provider
To integrate UAA with one or more LDAP servers, configure PKS with your LDAP endpoint information as follows:
1. Under **UAA**, select **LDAP Server**.<br>
1. For **Server URL**, enter the URLs that point to your LDAP server.
If you have multiple LDAP servers, separate their URLs with spaces.
Each URL must include one of the following protocols:
* `ldap://`: Use this protocol if your LDAP server uses an unencrypted connection.
* `ldaps://`: Use this protocol if your LDAP server uses SSL for an encrypted connection.
To support an encrypted connection, the LDAP server must hold a trusted certificate or you must import a trusted certificate to the JVM truststore.
1. For **LDAP Credentials**, enter the LDAP Distinguished Name (DN) and password for binding to the LDAP server.
For example, `cn=administrator,ou=Users,dc=example,dc=com`.
If the bind user belongs to a different search base, you must use the full DN.
<p class="note"><strong>Note</strong>: We recommend that you provide LDAP credentials that grant read-only permissions on the LDAP search base and the LDAP group search base.</p>
1. For **User Search Base**, enter the location in the LDAP directory tree where LDAP user search begins.
The LDAP search base typically matches your domain name.
<br><br>
For example, a domain named `cloud.example.com` may use `ou=Users,dc=example,dc=com` as its LDAP user search base.
1. For **User Search Filter**, enter a string to use for LDAP user search criteria.
The search criteria allows LDAP to perform more effective and efficient searches.
For example, the standard LDAP search filter `cn=Smith` returns all objects with a common name equal to `Smith`.
<br><br>
In the LDAP search filter string that you use to configure PKS, use `{0}` instead of the username.
For example, use `cn={0}` to return all LDAP objects with the same common name as the username.
<br><br>
In addition to `cn`, other common attributes are `mail`, `uid` and, in the case of Active Directory, `sAMAccountName`.
<p class="note"><strong>Note</strong>: For information about testing and troubleshooting your LDAP search filters, see <a href="https://community.pivotal.io/s/article/Configuring-LDAP-Integration-with-Pivotal-Cloud-Foundry">Configuring LDAP Integration with Pivotal Cloud Foundry</a>.</p>
1. For **Group Search Base**, enter the location in the LDAP directory tree where the LDAP group search begins.
<br><br>
For example, a domain named `cloud.example.com` may use `ou=Groups,dc=example,dc=com` as its LDAP group search base.
<br><br>
Follow the instructions in the [Grant PKS Access to an External LDAP Group](manage-users.html#external-group) section of _Managing Users in PKS with UAA_ to map the groups under this search base to roles in PKS.
1. For **Group Search Filter**, enter a string that defines LDAP group search criteria. The standard value is `member={0}`.
1. For **Server SSL Cert**, paste in the root certificate from your CA certificate or your self-signed certificate.<br>
1. For **Server SSL Cert AltName**, do one of the following:
* If you are using `ldaps://` with a self-signed certificate, enter a Subject Alternative Name (SAN) for your certificate.
* If you are not using `ldaps://` with a self-signed certificate, leave this field blank.
1. For **First Name Attribute**, enter the attribute name in your LDAP directory that contains user first names.
For example, `cn`.
1. For **Last Name Attribute**, enter the attribute name in your LDAP directory that contains user last names.
For example, `sn`.
1. For **Email Attribute**, enter the attribute name in your LDAP directory that contains user email addresses.
For example, `mail`.
1. For **Email Domain(s)**, enter a comma-separated list of the email domains for external users who can receive invitations to Apps Manager.
1. For **LDAP Referrals**, choose how UAA handles LDAP server referrals to other user stores.
UAA can follow the external referrals, ignore them without returning errors, or generate an error for each external referral and abort the authentication.
1. For **External Groups Whitelist**, enter a comma-separated list of group patterns which need to be populated in the user's `id_token`. For further information on accepted patterns see the description of the `config.externalGroupsWhitelist` in the OAuth/OIDC [Identity Provider Documentation](https://docs.cloudfoundry.org/api/uaa/version/4.19.0/index.html#oauth-oidc).
<p class="note"><strong>Note</strong>: When sent as a Bearer token in the Authentication header, wide pattern queries for users who are members of multiple groups, can cause the size of the <code>id_token</code> to extend beyond what is supported by web servers.</p>
1. Click **Save**.
#### <a id="configure-oidc"></a>(Optional) Configure OpenID Connect
You can use OpenID Connect (OIDC) to instruct Kubernetes to verify end-user identities based on authentication performed by an authorization server, such as UAA.
To configure PKS to use OIDC, select **Enable UAA as OIDC provider**. With OIDC enabled, Admin Users can grant cluster-wide access to Kubernetes end users.
For more information about configuring OIDC, see the table below:
<table class="nice">
<tr>
<th>Option</th>
<th>Description</th>
</tr>
<tr>
<td>OIDC disabled</td>
<td>If you do not enable OIDC, Kubernetes authenticates users against its internal user management system.</td>
</tr>
<tr>
<td>OIDC enabled</td>
<td>If you enable OIDC, Kubernetes uses the authentication mechanism that you selected in <a href="#uaa">UAA</a> as follows:
<ul>
<li>If you selected <strong>Internal UAA</strong>, Kubernetes authenticates users against the internal UAA authentication mechanism.</li>
<li>If you selected <strong>LDAP Server</strong>, Kubernetes authenticates users against the LDAP server.</li>
</ul>
</td>
</tr>
</table>
For additional information about getting credentials with OIDC configured, see [Retrieve Cluster Credentials](cluster-credentials.html#get-credentials) in _Retrieving Cluster Credentials and Configuration_.
<p class="note"><strong>Note</strong>: When you enable OIDC, existing PKS-provisioned Kubernetes clusters are upgraded to use OIDC. This invalidates your kubeconfig files. You must regenerate the files for all clusters.</p>