Configure an external identity provider
Big picture
Configure an external identity provider (IdP), create a user, and log in to Calico Enterprise Manager UI.
(If you are just starting out, the quickest way to allow user access is to configure the default, token authentication.)
Concepts
The Calico Enterprise authentication method is configured through the Authentication API resource named, tigera-secure
.
When configuring your cluster, you may be asked for the following inputs:
- Client Id: Id for exchanging data that are shared between the IdP and an application.
- Client Secret: Secret associated with the
client id
used by server applications for exchanging tokens. - Issuer URL: URL where the IdP can be reached, based on the conventions of OAuth and OIDC.
- Claims: Every time your IdP issues a token for a valid user, these claims add metadata about the user. Calico Enterprise uses this to determine the username.
Before you begin
Supported identity providers
- OIDC authentication: User identity is managed outside of the cluster by an OIDC authorization server.
- Google OIDC authentication: User identity is managed by Google OIDC. Choose this option if you want to use GSuite groups.
- OpenShift authentication: User identity is provided by the OpenShift OAuth server.
- LDAP authentication: User identify is provided using the LDAP server.
Required
How to
Configure an external identity provider for user authentication
- OIDC
- Google OIDC
- OpenShift
- LDAP
-
Apply the Authentication CR to your cluster to let the operator configure your login. The following example uses the email claim. The email field from the JWT (created by your IdP), is used as the username for binding privileges.
apiVersion: operator.tigera.io/v1
kind: Authentication
metadata:
name: tigera-secure
spec:
# This indicates where the Manager UI can be accessed from the browser. Include the port only if the manager UI is not running on port 443.
managerDomain: https://<domain-of-manager-ui>
oidc:
issuerURL: <your-idp-issuer>
usernameClaim: email -
Apply the secret to your cluster with your OIDC credentials. To get the values, consult the documentation of your provider.
apiVersion: v1
kind: Secret
metadata:
name: tigera-oidc-credentials
namespace: tigera-operator
data:
clientID: <your-base64-clientid>
clientSecret: <your-base64-clientid-secret>
-
Apply the Authentication CR to your cluster to let the operator configure your login. The following example uses the email claim. The email field from the JWT (created by your IdP), is used as the username for binding privileges.
apiVersion: operator.tigera.io/v1
kind: Authentication
metadata:
name: tigera-secure
spec:
managerDomain: https://<domain-of-manager-ui>
oidc:
issuerURL: <your-idp-issuer>
usernameClaim: email -
Optional: Google OIDC does not support the groups claim. However, Calico Enterprise leverages Dex IdP to add groups if you configure a service account. This account needs Domain-Wide Delegation and permission to access the
https://www.googleapis.com/auth/admin.directory.group.readonly
API scope. To get group fetching set up:- Follow the instructions to set up a service account with Domain-Wide Delegation
- During service account creation, a JSON key file will be created that contains authentication information for the service account.
- When delegating the API scopes to the service account, delegate the
https://www.googleapis.com/auth/admin.directory.group.readonly
scope and only this scope.
- Enable the Admin SDK
- Use the
serviceAccountSecret
andadminEmail
configuration options in the next step.- The contents of the JSON key file should be used as the
serviceAccountSecret
- For
adminEmail
choose a G Suite super user. The service account will impersonate this user when making calls to the admin API.
- The contents of the JSON key file should be used as the
- Follow the instructions to set up a service account with Domain-Wide Delegation
-
Apply the secret to your cluster with your OIDC credentials.
apiVersion: v1
kind: Secret
metadata:
name: tigera-oidc-credentials
namespace: tigera-operator
data:
clientID: <your-base64-clientid>
clientSecret: <your-base64-clientid-secret>
# If you created a service account in the previous step, include the following two fields.
serviceAccountSecret: <your-base64-json-contents>
adminEmail: <your-base64-gsuite-user>
-
Install the Openshift CLI (oc).
-
Create values for some required variables.
MANAGER_URL
is the URL where Calico Enterprise Manager will be accessed,CLUSTER_DOMAIN
is the domain (excl. port) where your OpenShift cluster is accessed (runoc status
to get it) andCLIENT_SECRET
is a value of your choosing.# This indicates where the Manager UI can be accessed from the browser. Include the port only if the manager UI is not running on port 443.
MANAGER_URL=<manager-host>:<port>
CLUSTER_DOMAIN=<domain-of-your-ocp-cluster>
CLIENT_SECRET=<clientSecret> -
Add an OAuthClient to your OpenShift cluster.
oc apply -f - <<EOF
kind: OAuthClient
apiVersion: oauth.openshift.io/v1
metadata:
# The name is used as the clientID by Dex.
name: tigera-dex
# The secret is used as the clientSecret by Dex
secret: $CLIENT_SECRET
# List of valid addresses for the callback.
redirectURIs:
- "$MANAGER_URL/dex/callback"
grantMethod: prompt
EOF -
Apply the Authentication CR to your cluster to let the operator configure your login.
oc apply -f - <<EOF
apiVersion: operator.tigera.io/v1
kind: Authentication
metadata:
name: tigera-secure
spec:
# This indicates where the Manager UI can be accessed from the browser. Include the port only if the manager UI is not running on port 443.
managerDomain: $MANAGER_URL
openshift:
issuerURL: https://api.$CLUSTER_DOMAIN:6443
EOF -
Get the certificates that are used to connect with OpenShift and store them in a file called
dex.pem
.echo | openssl s_client -servername oauth-openshift.apps.$CLUSTER_DOMAIN -connect oauth-openshift.apps.$CLUSTER_DOMAIN:443 | sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' > dex.pem
echo | openssl s_client -servername api.$CLUSTER_DOMAIN -connect api.$CLUSTER_DOMAIN:6443 | sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' >> dex.pemAlternatively, you can use the root CA of your cluster and store it in
dex.pem
. -
Apply a secret to your cluster with your OpenShift credentials.
oc create secret generic tigera-openshift-credentials -n tigera-operator --from-file=rootCA=dex.pem --from-literal=clientID=tigera-dex --from-literal=clientSecret=$CLIENT_SECRET
For detailed steps, see the Support KB article How to Configure LDAP Authentication with Active Directory.
-
Apply the Authentication CR to your cluster to let the operator configure your login.
apiVersion: operator.tigera.io/v1
kind: Authentication
metadata:
name: tigera-secure
spec:
# This indicates where the Manager UI can be accessed from the browser. Include the port only if the manager UI is not running on port 443.
managerDomain: https://<manager-host>:<port>
ldap:
# The host and port of the LDAP server. Example: ad.example.com:636.
host: <ldap-host>:<ldap-port>
# (optional) StartTLS whether to enable the startTLS feature for establishing TLS on an existing LDAP session.
# If true, the ldap protocol is used and then issues a StartTLS command, otherwise, connections will use
# the ldaps: protocol.
startTLS: true
# User entry search configuration.
userSearch:
# To start the user search from. Example: "cn=users,dc=example,dc=com".
baseDN: <base-dn>
# Optional filter to apply when searching the directory. Example: "(objectClass=posixAccount)"
filter: <filter>
# A mapping of attributes to the username. This value can be used for applying RBAC to a user.
Default: uid
nameAttribute: <name-attribute>
# (Optional) Group search configuration. This value can be used to apply RBAC to a user group.
groupSearch:
# BaseDN to start the search from. Example: "cn=groups,dc=example,dc=com".
baseDN: <base-dn>
# Optional filter to apply when searching the directory. Example: "(objectClass=posixGroup)"
filter: <filter>
# A mapping of attributes to the group name. This value can be used for applying RBAC to a user group. Example: "cn".
nameAttribute: <name-attribute>
# Following list contains field pairs that are used to match a user to a group. It adds an additional
# requirement to the filter that an attribute in the group must match the user's attribute value.
userMatchers:
- userAttribute: <user-attribute>
groupAttribute: <group-attribute> -
Apply the secret to your cluster with your LDAP credentials. To obtain the values, consult the documentation of your provider.
apiVersion: v1
kind: Secret
metadata:
name: tigera-ldap-credentials
namespace: tigera-operator
data:
bindDN: <your-base64-bind-dn>
bindPW: <your-base64-bind-password>
rootCA: <your-base64-ca-cert-pem>
Troubleshooting LDAP
Problem: Error: (502 bad gateway nginx) when logging in to Manager UI
Solution: nginx ingress cannot handle the length of the token when a groupSearch matches too many groups. To resolve this, apply a filter as shown in the following example.
apiVersion: operator.tigera.io/v1
kind: Authentication
name: tigera-secure
spec:
ldap:
groupSearch:
baseDN: OU=GroupID,OU=Groups,DC=mycompany,DC=com
filter: (&(objectClass=group)(|(cn=example-dn1)(cn=example-dn2)))
nameAttribute: cn
userMatchers:
- groupAttribute: member
userAttribute: distinguishedName
host: ldap.mycompany.com:636
startTLS: false
userSearch:
baseDN: OU=Accounts,DC=mycompany.com,DC=com
nameAttribute: userPrimaryName
managerDomain: https://tigera-manager.mycompany.com
Grant user login privileges
For OpenShift users, replace kubectl
with oc
in the following commands, or apply cluster roles from the OpenShift console: User Management, users.
For admin users, apply this cluster role.
kubectl create clusterrolebinding <user>-tigera-network-admin --user=<user> --clusterrole=tigera-network-admin
For basic users with view-only permissions, apply this role.
kubectl create clusterrolebinding <user>-tigera-ui-user --user=<user> --clusterrole=tigera-ui-user
Or use the groups flag to assign cluster role to a group of users.
kubectl create clusterrolebinding all-developers-tigera-ui-user --group=<group> --clusterrole=tigera-ui-user
(Optional) Allow Calico Enterprise URIs in your IdP
Most IdPs require redirect URIs to be allowed to redirect users at the end of the OAuth flow to the Calico Enterprise Manager or to Kibana. Consult your IdP documentation for authorizing your domain for the respective origins and destinations.
Authorized redirect URIs
https://<host><port>/dex/callback
Troubleshooting
- ManagerDomain
localhost
and127.0.0.1
are not the same. If you configurelocalhost:9443
as your managerDomain, while navigating tohttps://127.0.0.1:9443
, the OIDC security checks will deny you access. - Omit the port from
managerURL
if it is listening on the standard port (:443
) for HTTPS. - When your
usernameClaim
is notemail
andusernamePrefix
is omitted, we have implemented a default prefix identical to how Kubernetes has for their kube-apiserver, see the oidc-username-claim documentation. For example, if themanagerDomain
in yourAuthentication
spec ishttps://example.com
, and the username claim maps tojane
, the (cluster) role binding should be bound to:https://example.com/dex#jane
- When you encounter problems while configuring your IdP, we encourage you to use the network tab of the browser dev tools to inspect requests with error codes and to decode authorization headers of the HTTP requests.
- If you would like to bring a self-signed certificate for your IdP and are using OIDC, you can do so by adding the field
rootCA
to secrettigera-oidc-credentials
. The value for this field should contain the certificate in PEM format. - If logging into Kibana fails with a
cookie not present
error, update the browser settings to allow third-party cookies, as Calico Enterprise Manager UI uses Kibana's cookies during login. - If you need to configure LDAP with a DN that has spaces, use double quotes to escape them. For example:
cn="example common name",ou="example org unit",DC=example,DC=org
.