LogoLogo
5.0.X
5.0.X
  • About Trilio for Kubernetes
    • Welcome to Trilio For Kubernetes
    • Version 5.0.X Release Highlights
    • Compatibility Matrix
    • Marketplace Support
    • Features
    • Use Cases
  • Getting Started
    • Getting Started with Trilio on Red Hat OpenShift (OCP)
    • Getting Started with Trilio for Upstream Kubernetes (K8S)
    • Getting Started with Trilio for AWS Elastic Kubernetes Service (EKS)
    • Getting Started with Trilio on Google Kubernetes Engine (GKE)
    • Getting Started with Trilio on VMware Tanzu Kubernetes Grid (TKG)
    • More Trilio Supported Kubernetes Distributions
      • General Installation Prerequisites
      • Rancher Deployments
      • Azure Cloud AKS
      • Digital Ocean Cloud
      • Mirantis Kubernetes Engine
      • IBM Cloud
    • Licensing
    • Using Trilio
      • Overview
      • Post-Install Configuration
      • Management Console
        • About the UI
        • Navigating the UI
          • UI Login
          • Cluster Management (Home)
          • Backup & Recovery
            • Namespaces
              • Namespaces - Actions
              • Namespaces - Bulk Actions
            • Applications
              • Applications - Actions
              • Applications - Bulk Actions
            • Virtual Machines
              • Virtual Machine -Actions
              • Virtual Machine - Bulk Actions
            • Backup Plans
              • Create Backup Plans
              • Backup Plans - Actions
            • Targets
              • Create New Target
              • Targets - Actions
            • Hooks
              • Create Hook
              • Hooks - Actions
            • Policies
              • Create Policies
              • Policies - Actions
          • Monitoring
          • Guided Tours
        • UI How-to Guides
          • Multi-Cluster Management
          • Creating Backups
            • Pause Schedule Backups and Snapshots
            • Cancel InProgress Backups
            • Cleanup Failed Backups
          • Restoring Backups & Snapshots
            • Cross-Cluster Restores
            • Namespace & application scoped
            • Cluster scoped
          • Disaster Recovery Plan
          • Continuous Restore
      • Command-Line Interface
        • YAML Examples
        • Trilio Helm Operator Values
    • Upgrade
    • Air-Gapped Installations
    • Uninstall
  • Reference Guides
    • T4K Pod/Job Capabilities
      • Resource Quotas
    • Trilio Operator API Specifications
    • Custom Resource Definition - Application
  • Advanced Configuration
    • AWS S3 Target Permissions
    • Management Console
      • KubeConfig Authenticaton
      • Authentication Methods Via Dex
      • UI Authentication
      • RBAC Authentication
      • Configuring the UI
    • Resource Request Requirements
      • Fine Tuning Resource Requests and Limits
    • Observability
      • Observability of Trilio with Prometheus and Grafana
      • Exported Prometheus Metrics
      • Observability of Trilio with Openshift Monitoring
      • T4K Integration with Observability Stack
    • Modifying Default T4K Configuration
  • T4K Concepts
    • Supported Application Types
    • Support for Helm Releases
    • Support for OpenShift Operators
    • T4K Components
    • Backup and Restore Details
      • Immutable Backups
      • Application Centric Backups
    • Retention Process
      • Retention Use Case
    • Continuous Restore
      • Architecture and Concepts
  • Performance
    • S3 as Backup Target
      • T4K S3 Fuse Plugin performance
    • Measuring Backup Performance
  • Ecosystem
    • T4K Integration with Slack using BotKube
    • Monitoring T4K Logs using ELK Stack
    • Rancher Navigation Links for Trilio Management Console
    • Optimize T4K Backups with StormForge
    • T4K GitHub Runner
    • AWS RDS snapshots using T4K hooks
    • Deploying Trilio For Kubernetes with Openshift ACM Policies
  • Krew Plugins
    • T4K QuickStart Plugin
    • Trilio for Kubernetes Preflight Checks Plugin
    • T4K Log Collector Plugin
    • T4K Cleanup Plugin
  • Support
    • Troubleshooting Guide
    • Known Issues and Workarounds
    • Contacting Support
  • Appendix
    • Ignored Resources
    • OpenSource Software Disclosure
    • CSI Drivers
      • Installing VolumeSnapshot CRDs
      • Install AWS EBS CSI Driver
    • T4K Product Quickview
    • OpenShift OperatorHub Custom CatalogSource
      • Custom CatalogSource in a restricted environment
    • Configure OVH Object Storage as a Target
    • Connect T4K UI hosted with HTTPS to another cluster hosted with HTTP or vice versa
    • Fetch DigitalOcean Kubernetes Cluster kubeconfig for T4K UI Authentication
    • Force Update T4K Operator in Rancher Marketplace
    • Backup and Restore Virtual Machines running on OpenShift
    • T4K For Volumes with Generic Storage
    • T4K Best Practices
Powered by GitBook
On this page
  • Introduction
  • Pre-Requisites
  • Configuration

Was this helpful?

  1. Advanced Configuration
  2. Management Console

Authentication Methods Via Dex

This page describes how to setup and configure other forms of authentication via Dex.

PreviousKubeConfig AuthenticatonNextUI Authentication

Last updated 1 month ago

Was this helpful?

Useful Definitions

Authentication - Authentication is the process of verifying the identity of a user.

Authorization - Authorization is the process of determining if an identified user has access to a particular resource or not.

Connectors - When a user logs in through Dex, the user’s identity is usually stored in another user-management system: a LDAP directory, a GitHub org, etc. Dex acts as a shim between a client app and the upstream identity provider. A connector is a strategy used by Dex for authenticating a user against another identity provider. Dex implements connectors that target specific platforms such as GitHub, LinkedIn, and Microsoft as well as established protocols like LDAP and SAML.

Dex - Dex is an identity service that uses to drive authentication for other apps. Dex acts as a portal to other identity providers through connectors (see previous definition). This lets Dex defer authentication to LDAP servers, SAML providers, or established identity providers like GitHub, Google, and Active Directory. Clients write their authentication logic once to talk to Dex, then Dex handles the protocols for a given backend. For more information about Dex, .

LDAP/AD Auth Protocol - Lightweight Directory Access Protocol (LDAP) is an open and cross-platform application protocol for directory services authentication. Directory services, such as Active Directory (AD), store user information, account information, and security information like passwords. The service then allows the information to be shared with other devices on the network.

OIDC Auth Protocol - OpenID Connect (OIDC) is an authentication protocol based on the OAuth2 protocol (which is used for authorization). OIDC uses the standardized message flows from OAuth2 to provide identity services. It allows clients to confirm an end user's identity using authentication by an authorization server.

T4K Auth Support - T4K supports authentication via KubeConfig files and via Dex, which is an identity service IDP plugin that uses OpenID Connect to drive authentication for multiple applications, by deferring authentication to other identity providers like LDAP.

Introduction

Trilio For Kubernetes (T4K) uses Dex as a portal to other identity providers through connectors. For more information about these services, refer to the Useful References section at the top of this page.

A connector is a strategy used by Dex for authenticating a user against another identity provider. Dex implements connectors that target specific platforms such as GitHub, LinkedIn, and Microsoft as well as established protocols like LDAP.

Pre-Requisites

  1. LDAP / AD: LDAP protocol requires one read-only user who can perform LDAP searches to fetch users and groups.

  2. OpenShift: By default, OpenShift clusters already have Login Via OpenShift configured during the Trilio installation. T4K does not require any additional user input for that.

Configuration

STEP 1: Configure your OIDC authentication provider to allow authentication for T4K Web. Create a new application on the authentication provider portal, then use the T4K callback URL http(s):///dex/callback in the OIDC provider portal, and finally, generate client and secret keys. The following are links to achieve this for the most popular OIDC authentication providers:

The dex callback URL should contain a custom path in it for a custom path. for example custom path is "/t4k/" then dex callback URL will be http(s):///t4k/dex/callback.

  1. From the dropdown displayed, click OAuth client ID.

  2. Type a meaningful Name for the OAuth ID.

  3. Click Create.

Create a new application on the authentication provider portal, then use the TVK callback URL http(s):///dex/callback in the OIDC provider portal, and finally, generate client and secret keys.

Create a new application on the authentication provider portal, then use the TVK callback URL http(s):///dex/callback in the OIDC provider portal, and finally, generate client and secret keys.

Create a new application on the authentication provider portal, then use the TVK callback URL http(s):///dex/callback in the OIDC provider portal, and finally, generate client and secret keys.

  1. Ensure that the LDAP server is deployed and configured.

  2. Retrieve the following details from the LDAP server, as these are used in the next steps:

    • LDAP server host IP or FQDN e.g. ldap.tvkdemo.org

    • DNS domain name e.g. tvkdemo.org

    • bindDN: cn=username,dc=tvkdemo,dc=org

    • bindPW: password

  1. Type a meaningful name for application; i.e. TVK-UI-LOGIN.

  2. From the radio button options, choose who can use this application or access this API.

  3. Select Web from the dropdown menu.

  4. Type the redirect URI https://default.k8s-tvk.com/dex/callback.

  5. Click Register.

  6. Note down the following two details:

    • Application (client) ID, e.g. 27920363-a70c-4f26-8fb3-a89c57683a4f

    • Token endpoint - https://login.microsoftonline.com/48da23f5-8efc-4e39-b8cd-861508903cec

  7. On the screen displayed, select + New client secret.

  8. Click Add.

By default, OpenShift clusters already have Login Via OpenShift configured during the Triliovault installation. TVK does not require any additional user input for that, so Step 1 can be skipped for OpenShift.

  1. Login into Keycloak Management portal.

  2. Select the realm which use for authentication.

  3. Navigate to the Client Tab and copy Client name for ClientID

  1. Select the client and configure it with TVK URL and callback URL https://<TVK_URL>/dex/callback.

5. Go to Credential tab and Copy Your Client Secret values displayed.

Step 2: Prepare a secret.yaml file with the name triliovault-dex that has all the copied details of the authentication provider from Step 1 (Your Client ID and Your Client Secret). Refer to the relevant tab below to guide you how to form your secret.yaml for each of the main providers. You can choose other authentication providers and you can determine what details should be included in the associated secret.yaml file by reviewing the most common options below.

apiVersion: v1
kind: Secret
metadata:
  name: triliovault-dex
  namespace: <tvk-install-namespace>
type: Opaque
stringData:
  TVK_DEX_CONFIG: |-
    connectors:
    - type: google
      id: google
      name: Google
      config:
        clientID: xxxxx.apps.googleusercontent.com
        clientSecret: yyyyyyyyyyyyyyyyyyyy
        redirectURI: http://<ingress-domain>/dex/callback
apiVersion: v1
kind: Secret
metadata:
  name: triliovault-dex
  namespace: <tvk-install-namespace>
type: Opaque
stringData:
  TVK_DEX_CONFIG: |-
    connectors: 
    - type: github
      id: github
      name: GitHub
      config:
        clientID: xxxxxxxxxxxxxxxxxxxxx
        clientSecret: yyyyyyyyyyyyyyyyyyyyyyyy
        redirectURI: http://<ingress-domain>/dex/callback
apiVersion: v1
kind: Secret
metadata:
  name: triliovault-dex
  namespace: <tvk-install-namespace>
type: Opaque
stringData:
  TVK_DEX_CONFIG: |-
    connectors: 
    - type: linkedin
      id: linkedin
      name: LinkedIn
      config:
         clientID: 786xxxxxxxxxx
         clientSecret: 2myyyyyyyyyyy
         redirectURI: http://<ingress-domain>/dex/callback
apiVersion: v1
kind: Secret
metadata:
  name: triliovault-dex
  namespace: <tvk-install-namespace>
type: Opaque
stringData:
  TVK_DEX_CONFIG: |-
    connectors: 
    - type: gitlab
      id: gitlab
      name: Gitlab
      config:
         clientID: xxxxxxxxxxxxxxxxxxxxxxxxxxx
         clientSecret: yyyyyyyyyyyyyyyyyyyyyyyyyyyyyy
         redirectURI: http://<ingress-domain>/dex/callback
apiVersion: v1
kind: Secret
metadata:
  name: triliovault-dex
  namespace: <tvk-install-namespace>
type: Opaque
stringData:
  TVK_DEX_CONFIG: |-
    connectors: 
    - type: ldap
      id: ldap
      name: "LDAP"
      config:
        host: <ldap-host>
        startTLS: false
        insecureNoSSL: true
        insecureSkipVerify: true
        bindDN: "cn=admin,dc=trilio,dc=io"
        bindPW: <read-only-user-pass>
        usernamePrompt: "Username"
        userSearch:
          baseDN: "dc=trilio,dc=io"
          filter: ""
          username: cn
          idAttr: cn
          emailAttr: cn
          nameAttr: cn
        groupSearch:
          baseDN: "dc=trilio,dc=io"
          filter: ""
          userAttr: cn
          groupAttr: cn
          nameAttr: cn   

The following is a more detailed example with LDAP on SSL with multiple groups:

apiVersion: v1
kind: Secret
metadata:
 name: triliovault-dex
 namespace: <tvk-install-namespace>
 labels:
  triliovault.trilio.io/secret: triliovault-dex
type: Opaque
stringData:
 TVK_URL: https://cust1-trilio.scc.digital-tw.in
 TVK_DEX_CONFIG: |-
  connectors: 
  - type: ldap
    id: ldap
    name: "LDAP"
    config:
     host: vse.triliostaging.com:636
     rootCAData: <crt.pem>
     usernamePrompt: "Username"
     userSearch:
      baseDN: "cn=users,cn=compat,dc=triliostaging,dc=com"
      filter: ""
      username: uid
      idAttr: uid
      emailAttr: cn
      nameAttr: cn
     groupSearch:
      baseDN: "cn=groups,cn=compat,dc=triliostaging,dc=com"
      filter: "(|(cn=group1)(cn=group2))"
      userAttr: uid
      groupAttr: memberuid
      nameAttr: cn
apiVersion: v1
kind: Secret
metadata:
  name: triliovault-dex
type: Opaque
stringData:
  TVK_DEX_CONFIG: |-
    connectors: 
    - type: oidc
      id: azure
      name: azure
      config:
        insecureSkipEmailVerified: true
        issuer: https://login.microsoftonline.com/0d4a2397-be27-42b5-9613-6650908518bc/v2.0
        clientID: xxxxxxxxxx
        clientSecret: yyyyyyyyyyyyy
        redirectURI: http://<ingress-domain>/dex/callback
apiVersion: v1
kind: Secret
metadata:
  name: triliovault-dex
  namespace: <tvk-install-namespace>
type: Opaque
stringData:
  TVK_DEX_CONFIG: |-
    connectors: 
    - type: openshift
      id: openshift
      name: OpenShift
      config:
        issuer: <OCP-api-url>
        clientID: system:serviceaccount:openshift-operators:<serviceaccount>
        clientSecret: yyyyyyyyyyyyyyyyy
        redirectURI: http://<ingress-domain>/dex/callback
        insecureCA: true
apiVersion: v1
kind: Secret
metadata:
  name: triliovault-dex
  namespace: <tvk-install-namespace>
type: Opaque
stringData:
  TVK_DEX_CONFIG: |-
    connectors: 
    - type: oidc
      id: azure
      name: azure
      config:
        insecureSkipEmailVerified: true
        issuer: https://<login-endpoint>
        clientID: xxxxxxxxxxxxx
        clientSecret: yyyyyyyyyyyyyyyyyyyyyy
        redirectURI: http://<ingress-domain>/dex/callback
apiVersion: v1
kind: Secret
metadata:
  name: triliovault-dex
  namespace: <tvk-install-namespace>
type: Opaque
stringData:
  TVK_DEX_CONFIG: |-
    connectors:
    - type: oidc
      id: keycloak
      name: keycloak
      config:
        issuer: https://<KeyCloak URL>
        clientID: XXXXXXX
        clientSecret: yyyyyyyyyyyyyyyyyyyy
        redirectURI: https://<ingress-domain>/dex/callback
        scopes:
        - openid
        - profile
        - email
        insecureSkipEmailVerified: true
        insecureEnableGroups: true
        insecureSkipVerify: true
        userIDKey: email
        userNameKey: email

Step 3 (Optional) - Only if using 'Port Forwarding' or 'NodePort', update your secret.yaml file created in Step 1 with an additional key T4K_URL. This provides your custom URL with a port to access the T4K dashboard.

  • Insert a new line in the secret.yaml file immediately after code line 9 (applies to all examples given in Step 1) and insert the following: TVK_URL: http://<ingress-domain>:1234

  • Save the secret YAML file using the same name as before.

Step 4: Apply the new secret.yaml in the namespace of the k8s cluster where T4K is installed.

kubectl apply -f <secret.yaml> -n <tvk-namespace>

This causes the creation of the T4K Dex deployment, which will reflect changes on the T4K Management Console UI. You will now find another way of logging in, according to what you have just configured, i.e. Login Via Github.

Step 5: Create a cluster role binding using the below command, making sure to replace the user with your user/email ID and the clusterrolebinding name, since it must be unique:

kubectl create clusterrolebinding admin-binding-1 --clusterrole=cluster-admin --user=<Google ID>

Step 6: Navigate to the Management Console UI login page. You will now see an additional login method, which corresponds to what you have just configured in the previous steps; e.g. Login Via Github.

For LDAP, you will be prompted for your Username and Password.

Navigate to the Google application's API page.

Click + Create Credentials.

In the Application type field, use the dropdown menu to select Web application.

Add authorized redirect URIs as the TVK call back URL. For example, for the NodePort use and for the LoadBalancer use:

Copy Your Client ID and Your Client Secret values displayed.

Navigate to the GitHub application:

Navigate to the LinkedIn application:

Navigate to the GitLab application:

Navigate to the Azure Home > App registrations > Register an application:()

In Azure's left menu panel, select Certificates & Secrets.

In the pop-up window displayed, type a meaningful Description for your client secret, e.g. TVK UI Login Secret. Also set an expiry period.

The Client secrets tab automatically displays available secrets. Copy the Value for the secret just added.

Using the copied value from the previous step, configure the TVK Management Console access over HTTPS. Refer to the following documentation guide:

Refer for all other configuration details of all other connectors and any customer configurations required.

Credentials
https://github.com/settings/applications/new
https://developer.linkedin.com/
https://gitlab.com/-/profile/applications
this doc
OpenID Connect
click here
http://default.k8s-tvk.com:32663/dex/callback
http://gke-270.k8s-tvk.demo.trilio.io/dex/callback
https://portal.azure.com/#blade/Microsoft_AAD_RegisteredApps/ApplicationsListBlade
Here
How Dex works
Trilio Authenticaton - GitHub example