Configuring Okta as an Identity Provider for Kubernetes Clusters

Okta is a platform for managing identities and access in the cloud that offers safe and simple access to numerous programs and services. As a centralized and cloud-based identity provider, it enables enterprises to handle user authentication, authorization, and user lifecycle management.

Users can access several on-prem applications and cloud-based services with a single set of credentials through Okta's Single Sign-On (SSO) capabilities. Multi-factor authentication (MFA) can be easily configured as an additional security measure.

The platform integrates with various infrastructure services, platform offerings, and SaaS services, including web and mobile applications and APIs. Okta offers a user-friendly interface and API enabling programmers to create secure authentication and authorization workflows.

Organizations use Okta to improve user experience, increase security, and simplify identity and access management.

Teleport is one of the first identity-native infrastructure access platforms for both engineers and machines. It enables phishing-proof zero trust for every engineer and service that is connected to an organization’s global infrastructure, which is achieved by replacing insecure secrets with actual identities. The open source Teleport Access Platform offers a seamless developer experience as a single source of truth for infrastructure access.

Teleport can be easily configured to use Okta SSO for authentication and authorization to infrastructure resources like Linux and Windows Servers, Kubernetes Clusters, Databases, Monitoring Dashboards, CI/CD systems, and more. Customers can easily implement role-based access control (RBAC) for fine-grained authorization by mapping Okta groups to Teleport roles.

This series of tutorials will walk you through the steps involved in leveraging Okta as an identity provider for Kubernetes clusters managed by Teleport. Each tutorial focuses on configuring a cluster based on a mainstream Kubernetes distribution or a managed service running the cloud.

The first part of this series introduces the context and the steps involved in preparing Okta as an SSO provider for Teleport.

Background

An enterprise uses Okta as a centralized identity management platform to maintain the corporate directory of people and groups. These users and groups are independent of the identity managed by individual applications, platform services, and infrastructure such as Linux servers, Windows servers, databases, and Kubernetes clusters.

There are multiple groups created within Okta, such as administrators, developers, and operators. Since these groups are mapped to the roles and groups of external applications and resources, adding or removing users from these groups automatically allows or restricts access.

As a part of the move towards Zero Trust, the customer has deployed Teleport as an identity-native proxy to secure various assets such as servers, virtual machines, cloud resources, and Kubernetes clusters. They want to leverage the same authentication mechanism based on Okta to access the assets managed by Teleport.

The Teleport authentication and proxy service are deployed at proxy.teleport-demo.in endpoint, through which the users are authenticated and authorized to access various resources registered with Teleport.

This tutorial aims to explain the high-level steps in configuring Okta as an SSO provider for Teleport. For detailed instructions, please refer to the Teleport documentation.

Step 1 - Configuring Okta for SSO

Okta has a set of users, groups, and external applications registered with it. As seen above, the users are already a part of one or more groups based on their roles, such as developers and operators.

Teleport is registered as an external application assigned to the users.

All the users have been assigned to the Teleport application.

Okta is configured to call back the Teleport URL after a user is authenticated to facilitate single sign-on. The below screenshot shows the SAML settings that associate Teleport API endpoints and Okta user/group attributes.

Notice the values mentioned for the URLs, which are pointed to Teleport’s API endpoint. The user and group attributes are passed onto Teleport to map them to individual roles with appropriate permissions to access resources.

Step 2 - Connecting Teleport to Okta

In this step, we will configure the Teleport authentication server to use Okta as the SSO provider. For details on installing and configuring Teleport Enterprise, refer to the documentation.

A YAML file defines the Okta connector establishing the association between the two.

kind: saml
version: v2
metadata:
  # the name of the connector
  name: okta
spec:
  # connector display name that will be appended to the title of "Login with"
  # button on the cluster login screen so it will say "Login with Okta"
  display: Okta
  # SAML provider will make a callback to this URL after successful authentication
  # cluster-url is the address the cluster UI is reachable at
  acs: https://proxy.teleport-demo.in:443/v1/webapi/saml/acs
  attributes_to_roles:
  - name: groups
    roles:
    - editor
    value: okta-admin
  - name: groups
    roles:
    - access
    value: okta-dev
  - name: groups
    roles:
    - access
    value: okta-ops
  # Note that the entire XML document is indented by 4 spaces. This is
  # required because the pipe symbol indicates what follows is raw text.
  # Below is an Example. Replace with your XML
  entity_descriptor: |
      <IDP Metadata>

We are mapping the Teleport roles, auditor, and access, to the okta-admin group defined in Okta. The IDP metadata contains critical information about the SAML SSO provider specific to Okta.

After logging into Teleport as a local user with the auditor and access roles, create the connector with the below command:

tctl create -f okta-connector.yaml

Finally, add the below content to the file, /etc/teleport.yaml, and restart the Teleport service.

auth_service:
  authentication:
    type: saml

We are now ready to use Okta as the SSO provider for Teleport. Access the URL https://proxy.teleport-demo.in to see the login with the Okta button.

Users can also log in from the CLI, which automatically opens the browser window for authentication.

In the next part of this tutorial, we will explore how to attach a Kubernetes cluster based on upstream, open source distribution to Teleport and access it through Okta. Stay tuned.