Authentication

Active Directory

CCME needs to connect to an Active Directory (or LDAP server) to authenticate the users. You can either let CCME deploy an Active directory, or use your own Active Directory. Both the CCME Management Host and the HPC clusters will connect to the Active Directory through LDAPs, no join is done on the Active Directory domain.

Authentication configuration is done when you create the CCME Management Host (CMH), see the following variables in deployment.ccme.conf (see CMH Configuration): active_directory_name, active_directory_ips, active_directory_read_only_user_dn active_directory_read_only_user_password_secret_arn and active_directory_admin_password_secret_arn. The CMH will configure the ParallelCluster configuration files according to the selected parameters, and the clusters will automatically configure SSSD (System Security Services Daemon) to authenticate users.

You can specifie a filter to limit directory access to a subset of users through the use of the LdapAccessFilter option in the ParallelCluster configuration file.

Note

On Linux, sssd caches the users after their connection to the instance. You can need to clear the cache if a uid/gid user or group has been changed in the AD with the following command:

systemctl stop sssd
rm -rf /var/lib/sss/db/*
systemctl start sssd

Warning

If you do Windows remote visualization (see Windows) you will need to configure authentication directly in the AMI or through a custom powershell script that will configure the instance at launch time.

CCME Active Directory

CCME can deploy its own Active Directory when you set active_directory_ips=NONE in deployment.ccme.conf: an AWS Managed Directory Service is then deployed, and shared among all the clusters and the CMH.

In this case, you must provide the ARN to a secret containing the password for the administrator (see active_directory_admin_password_secret_arn).

Self-managed Active Directory

You can also use your own Active Directory. You just need to configure the deployment.ccme.conf accordingly.

OIDC External Authentication

Optional external authentication is available only for EnginFrame, through the Application Load Balancer and an OIDC-compatible SSO system.

In order to create a configuration file for the Open ID authentication, a basic configuration file is available in the CCME/conf/ directory. You must duplicate this file (in the same directory) and name the new file following the next pattern: ${CCME_OIDC}.oidc.yaml, with ${CCME_OIDC} the parameter you specified in ParallelCluster configuration file.

Note

Using OIDC authentication for EnginFrame does not prevent the use of a source of authentication for the clusters. You can use either the Active Directory deployed by CCME or your own.

Example in bash:

cp "CCME/conf/default.oidc.yaml" "CCME/conf/${CCME_OIDC}.oidc.yaml"

Content of CCME/conf/default.oidc.yaml:

 1################################################################################
 2# Copyright (c) 2017-2023 UCit SAS
 3# All Rights Reserved
 4#
 5# This software is the confidential and proprietary information
 6# of UCit SAS ("Confidential Information").
 7# You shall not disclose such Confidential Information
 8# and shall use it only in accordance with the terms of
 9# the license agreement you entered into with UCit.
10################################################################################
11# Authentication connectivity
12Issuer: 'url'
13AuthorizationEndpoint: 'url'
14TokenEndpoint: 'url'
15UserInfoEndpoint: 'url'
16# ARN of credentials stored in AWS Secret Manager
17ClientCredentials: 'arn'
18# Variable
19SessionCookieName: 'string'

The variable ClientCredentials should be filled with the ARN of credentials stored in AWS Secrets Service Manager.

Example of ARN syntax:

arn:aws:secretsmanager:${aws_region}:${aws_account_id}:secret:${secrets_manager_prefix}-oidc-credentials-4J3int

The credentials stored in the secret should be:

{
  "ClientId": "${your_client_id}",
  "ClientSecret": "${your_client_secret}"
}