CDP partie 4 : gestion des utilisateurs sur CDP avec Keycloak
4 juil. 2023
Ne ratez pas nos articles sur l'open source, le big data et les systèmes distribués, fréquence faible d’un email tous les deux mois.
Les articles précédents de la série couvrent le déploiement d’un environnement CDP Public Cloud. Tous les composants sont prêts à être utilisés et il est temps de mettre l’environnement à la disposition d’autres utilisateurs pour qu’ils puissent explorer tous les services et mener leurs expériences.
Cet article est le quatrième d’une série de six :
- CDP partie 1 : introduction à l’architecture Data Lakehouse avec CDP
- CDP partie 2 : déploiement d’un environnement CDP Public Cloud sur AWS
- CDP partie 3 : activation des Data Services en environnement CDP Public Cloud
- CDP partie 4 : gestion des utilisateurs sur CDP avec Keycloak
- CDP partie 5 : gestion des permissions utilisateurs sur CDP
- CDP partie 6 : cas d’usage bout en bout d’un Data Lakehouse avec CDP
L’intégration des utilisateurs dans un environnement et des services CDP peut se faire de deux manières : en configurant un fournisseur d’identité ou en important des utilisateurs en masse.
Cet article se concentre sur la configuration de Keycloak en tant que fournisseur d’identité (IdP) pour CDP. Keycloak nous permet de mettre en place une fédération d’identité avec CDP car il prend en charge le protocole Security Assertion Markup Language (SAML 2.0). La fédération d’identité permet aux utilisateurs de se connecter à la console CDP via l’authentification Keycloak sans s’inscrire auprès de Cloudera ou créer un compte Cloudera.
L’intégration des utilisateurs et la configuration de Keycloak en tant que fournisseur d’identité pour CDP se font via l’interface web de Keycloak (console d’administration) ou en utilisant le terminal. Les deux approches sont couvertes.
Du côté de CDP, les rôles Administrateur de compte
ou PowerUser
sont nécessaires pour mener à bien ce processus
Déployer Keycloak à l’aide d’une instance AWS EC2
Il est clair que nous devons déployer Keycloak avant de commencer la configuration du fournisseur d’identité dans CDP.
Pour déployer Keycloak avec une installation minimale pour que les utilisateurs puissent se connecter via internet, nous le déployons avec Docker dans une instance AWS EC2.
Pour se faire, vous avez besoin d’une instance EC2 avec les caractéristiques suivantes :
- Type d’instance :
t2.micro
- AMI :
ami-05e9058d6cda9ba0d
- Docker compose installé
- Adresse IP publique
- Règle entrante sur le port
8443
Une fois que vous avez créé l’instance, prenez note des informations suivantes :
- DNS IPv4 public :
<PUBLIC_IPV4_DNS>
- Adresse IP publique :
<ec2_public_ip>
- Paire de clés EC2 :
<AWS_SSH_KEY>
Pour un guide complet sur le lancement d’une instance AWS EC2 qui répond à ces exigences, consultez cet article Configurer Keycloak dans une instance EC2.
Une fois que votre instance EC2 est prête, vous êtes prêt à commencer le déploiement de Keycloak.
Machine locale :
Définir les variables requises pour l’instance EC2
export PUBLIC_IPV4_DNS=<PUBLIC_IPV4_DNS>
export AWS_SSH_KEY=<AWS_SSH_KEY>
# Nom d'utilisateur par défaut pour Amazon Linux AMI
export EC2_USERNAME=ec2-user
Connexion à l’instance EC2 :
ssh -i "~/.ssh/${AWS_SSH_KEY}.pem" ${EC2_USERNAME}@${PUBLIC_IPV4_DNS}
Instance EC2 :
Créez le fichier docker-compose.yml
:
cat <<EOF > docker-compose.yml
version: '3'
services:
keycloak:
# The 20.0.0 keycloak image
image: quay.io/keycloak/keycloak:20.0.0
container_name: keycloak
environment:
# Keycloak admin credentials
KEYCLOAK_ADMIN: admin
KEYCLOAK_ADMIN_PASSWORD: Password123
ports:
# The HTTPS port
- 8443:8443
# The HTTP port
- 8080:8080
command: start-dev
volumes:
# To save the SAML metadata file
- ./kc_config:/kc_config
volumes:
kc_config:
external: true
EOF
Créer le dossier du volume externe :
mkdir kc_config
Lancez le docker compose :
docker compose up -d
Vérifiez que Keycloak fonctionne avec Docker :
docker ps
Pour avoir accès à la console d’administration de Keycloak (interface web de Keycloak), vous devez désactiver le protocole SSL :
-
Entrez dans le conteneur :
docker exec -it keycloak bash
-
Ajouter le chemin requis pour utiliser le script
kcadm.sh
:export PATH=$PATH:/opt/keycloak/bin
-
Indiquez le serveur et les informations d’identification pour le domaine
master
:kcadm.sh config credentials --server http://localhost:8080/ \ --realm master \ --user $KEYCLOAK_ADMIN \ --password $KEYCLOAK_ADMIN_PASSWORD
-
Désactiver le SSL pour le domaine
master
:kcadm.sh update realms/master -s enabled=true -s sslRequired=none
-
L’interface web de Keycloak est maintenant disponible à l’adresse suivante :
http://<ec2_public_ip>:8080
.
Configuration à l’aide de l’interface Web de Keycloak
Il est recommandé d’utiliser l’interface web de Keycloak si vous n’êtes pas familier avec Keycloak et si vous souhaitez mieux comprendre comment lier CDP à Keycloak.
Si vous préférez commencer par une approche facile à reproduire, qui vous permet d’effectuer la configuration et de créer des utilisateurs plus rapidement, faites défiler vers le bas jusqu’à la section Configuration à partir du terminal.
Création de domaine (Realm)
Le Realm est l’un des concepts fondamentaux de Keycloak. Un Realm sécurise et gère les métadonnées de sécurité pour un ensemble d’utilisateurs.
Pour créer un Realm :
-
Naviguez jusqu’à
http://<ec2_public_ip>:8080
, cliquez sur Administration Console : -
Connectez-vous en utilisant votre
KEYCLOAK_ADMIN
etKEYCLOAK_ADMIN_PASSWORD
défini dans le fichierdocker-compose.yml
: -
Cliquez sur le menu déroulant dans le coin supérieur gauche où il est indiqué master, puis cliquez sur Create Realm :
-
Remplissez le nom et cliquez sur Create :
-
Naviguez jusqu’à Realm settings et cliquez sur SAML 2.0 Identity Provider Metadata :
-
Cela ouvre un autre onglet avec les métadonnées SAML requises pour enregistrer la zone en tant qu’IdP dans CDP :
-
Téléchargez ce fichier dans le format xml. Right click > Save Page As… > saml_metada.xml :
-
Pour désactiver l’exigence de SSL : retournez à Realm settings sélectionner l’onglet General, fixez la valeur de Required SSL à None et cliquez sur Save :
Enregistrement de Keycloak dans CDP
Dans cette étape, Keycloak est enregistré en tant que fournisseur d’identité dans CDP. Pour ce faire, le fichier de métadonnées SAML précédemment téléchargé est nécessaire.
Pour rappel, vous devez disposer des rôles Account administrator
ou PowerUser
dans votre compte CDP pour mener à bien ce processus.
Pour créer le fournisseur d’identité dans CDP, les étapes suivantes sont nécessaires.
-
Accedez a votre CDP Console et sélectionnez Management Console :
-
Naviguez vers User Management > Identity Providers > Create Identity Provider :
-
Créer un fournisseur d’identité :
- Saisissez le nom que vous souhaitez utiliser pour le fournisseur d’identité CDP.
- Cochez l’option Synchroniser les groupes à l’ouverture de session : Cette option synchronise l’appartenance à un groupe d’utilisateurs dans CDP avec l’appartenance à un groupe d’utilisateurs dans Keycloak.
- Dans Provider Metadata, sélectionnez File Upload et envoyez le fichier
saml_provider.xml
téléchargé à l’étape précédente. - Cliquez sur Create.
-
Copiez l’
<ID>
généré après le processus de création
Cet <ID>
est ajouté à notre configuration Keycloak dans l’étape suivante.
Créer le client CDP sur Keycloak
Dans cette étape, le client du plan de contrôle CDP est créé dans notre déploiement Keycloak.
Il y a deux façons de créer un client dans Keycloak :
- En utilisant un descripteur d’entité : importer le client en utilisant un fichier json SAML Entity Descriptor standard.
- Manuellement via l’interface utilisateur Keycloak en utilisant les métadonnées CDP SAML Service Provider Metadata disponibles dans le fournisseur d’identité créé à l’étape précédente. (Voir Managing OpenID Connect and SAML Clients pour plus de détails).
Dans ce cas, nous utilisons un fichier SAML Entity Descriptor : cdp-client.
Remarque : Le cdp-client a été trouvé dans cet article : How to configure Single Sign-On (SSO) for CDP Public Cloud the open-source way with Keycloak.
L’auteur précise que ce fichier n’est ni officiel ni fourni par Cloudera, mais qu’il inclut les paramètres requis, l’assertion SAML et les certificats de signature requis par CDP.
Pour créer un client SAML 2.0 dans Keycloak en important un fichier de configuration, suivez les étapes suivantes :
-
Dans la console d’administration de Keycloak, naviguez vers Clients et cliquez sur Créer.
-
Cliquez sur Browse et chargez le fichier cdp-client. Cela met automatiquement à jour les paramètres Identification du client et Type. Cliquez sur Save
-
Pour obtenir l’URL de la page de connexion, accédez à l’onglet Settings et descendez jusqu’à la variable IDP Initiated SSO URL Name.
Elle devrait ressembler à ceci :
http://<ec2_public_ip>:8080/realms/adaltas-cdp-lab/protocol/saml/clients/cdp-sso
. -
Accédez à l’onglet Advanced, remplacez
${CDP_IdP_ID}
par l’ID du fournisseur d’identité généré par le CDP à l’étape précédente. Faites défiler vers le bas et cliquez sur Save -
Testez la Login Page URL :
Gérer les groupes et les utilisateurs
Maintenant que le Realm et le client sont prêts, nous créons/gérons les utilisateurs et les groupes via la console d’administration.
Créer un groupe :
-
Naviguez vers Groups dans le menu de gauche, et cliquez sur Create group :
-
Remplissez le nom et cliquez sur Save :
Note : Faites attention en choisissant le
GROUP_NAME
car il y a une liste de noms de groupes qui sont réservés et qui ne peuvent donc pas être synchronisés avec CDP.
Créer un utilisateur :
-
Naviguez vers Users dans le menu de gauche, et cliquez sur Create new user :
-
Définissez les paramètres suivants et cliquez sur Create :
- Nom d’utilisateur
- Prénom
- Nom de famille
- Sélectionnez le groupe créé précédemment
-
Pour définir le mot de passe, naviguez jusqu’à Credentials, remplissez les valeurs et cliquez sur Set Password :
-
Testez l’utilisateur en se connectant :
Configuration à partir du terminal
Cette approche s’adresse aux utilisateurs plus familiers avec Keycloak ou à ceux qui souhaitent un processus automatisé.
Comme vous l’avez peut-être déjà remarqué, la configuration de Keycloak à l’aide de l’interface web peut être fastidieuse et un peu longue. L’interface web n’est pas la meilleure idée pour ceux qui ont affaire à de grands groupes ou même simplement à des fins de test, surtout en ce qui concerne la création d’utilisateurs.
La configuration via le terminal nécessite les étapes suivantes :
- Se connecter et vérifier les exigences EC2
- Créer les informations d’identification et se connecter au Realm Master
- Créer le Realm et télécharger les métadonnées SAML
- Enregistrer Keycloak dans CDP
- Créer un client CDP
- Créer des utilisateurs
- Créer un groupe et ajouter des utilisateurs
Connexion et vérification des exigences EC2
Comme nous l’avons mentionné précédemment, nous supposons que Keycloak fonctionne à l’aide de Docker Compose sur une instance EC2.
Par conséquent, nous allons nous connecter à cette instance EC2 et aller à l’intérieur du conteneur Docker pour exécuter toutes les commandes.
Machine locale :
-
Définissez les variables requises pour l’instance EC2 :
export PUBLIC_IPV4_DNS=<PUBLIC_IPV4_DNS> export AWS_SSH_KEY=<AWS_SSH_KEY> # Utilisateur par défault pour l'AMI Ubuntu export EC2_USERNAME=ec2-user
Connectez-vous à l’instance EC2 et verifiez que les fichiers sont là :
ssh -i "~/.ssh/${AWS_SSH_KEY}.pem" ${EC2_USERNAME}@${PUBLIC_IPV4_DNS}
Le conteneur Docker est en cours d’exécution et vous devriez avoir la configuration suivante :
./ubuntu
├── docker-compose.yml
└── kc_config
1 directories, 1 file
Nous sommes maintenant prêts à lancer le processus de configuration.
Instance EC2 :
-
Entrez dans le conteneur :
docker exec -it keycloak bash
-
Naviguez jusqu’au répertoire du volume externe :
cd kc_config
Créer des informations d’identification et se connecter au Realm Master
Cette étape permet de créer un justificatif d’identité Truststore nécessaire pour se connecter au Realm Master via le terminal.
# Chemin requis pour utiliser le script kcadm.sh
export PATH=$PATH:/opt/keycloak/bin
# Se connecter au Realm Master
kcadm.sh config credentials --server http://localhost:8080/ \
--realm master \
--user $KEYCLOAK_ADMIN \
--password $KEYCLOAK_ADMIN_PASSWORD
Créer le Realm et télécharger les métadonnées SAML
Il est maintenant temps d’enregistrer notre Realm et d’obtenir les métadonnées SAML nécessaires pour enregistrer Keycloak en tant qu’IdP dans CDP.
# Définir le nom du Realm
export REALM="adaltas-cdp-lab"
# Définir le nom du fichier de métadonnées SAML
export SAML_FILE=saml_provider.xml
# Créer le domaine sans SSL
kcadm.sh create realms \
--set realm=$REALM \
--set enabled=true \
--set sslRequired=none
# Télécharger le fichier de métadonnées SAML
curl \
-k http://localhost:8080/realms/adaltas-cdp-lab/protocol/saml/descriptor \
> $SAML_FILE
Puisque nous avons besoin de ce fichier dans l’étape suivante, utilisez la commande ci-dessous pour copier les métadonnées SAML
sur votre machine locale :
scp -i "~/.ssh/${AWS_SSH_KEY}.pem" ${EC2_USERNAME}@${PUBLIC_IPV4_DNS}:/home/${EC2_USERNAME}/kc_config/saml_provider.xml ./
Enregistrement de Keycloak dans CDP
Utilisez l’interface web de Cloudera pour enregistrer Keycloak en tant qu’IdP comme décrit dans l’approche de l’interface web.
Note : Au moment de la rédaction de l’article, ce processus ne pouvait pas être exécuté via la CLI CDP car la commande cdp iam create-saml-provider ne fonctionnait pas.
Créer un client CDP
Dans cette étape, nous allons créer le client CDP sur Keycloak en utilisant le contenu du fichier cdp_client et l’ <ID>
généré par CDP à l’étape précédente.
# Définir l'ID IdP généré par CDP à l'étape précédente
export CDP_IdP_ID=<ID>
# Créer le client
kcadm.sh create clients --target-realm $REALM -f - << EOF
{
"clientId": "cdp-client",
"surrogateAuthRequired": false,
"enabled": true,
"clientAuthenticatorType": "client-secret",
"redirectUris": [
"https://consoleauth.altus.cloudera.com/saml"
],
"webOrigins": [
"https://consoleauth.altus.cloudera.com"
],
"notBefore": 0,
"bearerOnly": false,
"consentRequired": false,
"standardFlowEnabled": true,
"implicitFlowEnabled": false,
"directAccessGrantsEnabled": false,
"serviceAccountsEnabled": false,
"publicClient": false,
"frontchannelLogout": true,
"protocol": "saml",
"attributes": {
"saml.assertion.signature": "true",
"saml.force.post.binding": "true",
"saml.multivalued.roles": "false",
"saml.encrypt": "false",
"saml_assertion_consumer_url_post": "https://consoleauth.altus.cloudera.com/saml?samlProviderId=${CDP_IdP_ID}",
"saml.server.signature": "true",
"saml_idp_initiated_sso_url_name": "cdp-sso",
"saml.server.signature.keyinfo.ext": "false",
"exclude.session.state.from.auth.response": "false",
"saml.signature.algorithm": "RSA_SHA256",
"saml_force_name_id_format": "false",
"saml.client.signature": "true",
"tls.client.certificate.bound.access.tokens": "false",
"saml.authnstatement": "true",
"display.on.consent.screen": "false",
"saml_name_id_format": "username",
"saml.onetimeuse.condition": "false",
"saml_signature_canonicalization_method": "http://www.w3.org/2001/10/xml-exc-c14n#"
},
"authenticationFlowBindingOverrides": {},
"fullScopeAllowed": true,
"nodeReRegistrationTimeout": -1,
"protocolMappers": [
{
"name": "my-email-id-mapper",
"protocol": "saml",
"protocolMapper": "saml-user-property-mapper",
"consentRequired": false,
"config": {
"attribute.nameformat": "URI Reference",
"user.attribute": "email",
"friendly.name": "my-email-friendly-name",
"attribute.name": "urn:oid:0.9.2342.19200300.100.1.3"
}
},
{
"name": "my-groups-mapper",
"protocol": "saml",
"protocolMapper": "saml-group-membership-mapper",
"consentRequired": false,
"config": {
"single": "true",
"attribute.nameformat": "URI Reference",
"full.path": "false",
"friendly.name": "my-groups-friendly-name",
"attribute.name": "https://altus.cloudera.com/SAML/Attributes/groups"
}
},
{
"name": "my-firstname-mapper",
"protocol": "saml",
"protocolMapper": "saml-user-property-mapper",
"consentRequired": false,
"config": {
"attribute.nameformat": "URI Reference",
"user.attribute": "firstName",
"friendly.name": "my-firstname-friendly-name",
"attribute.name": "https://altus.cloudera.com/SAML/Attributes/firstName"
}
},
{
"name": "my-lastname-mapper",
"protocol": "saml",
"protocolMapper": "saml-user-property-mapper",
"consentRequired": false,
"config": {
"attribute.nameformat": "URI Reference",
"user.attribute": "lastName",
"friendly.name": "my-lastname-friendly-name",
"attribute.name": "https://altus.cloudera.com/SAML/Attributes/lastName"
}
}
],
"defaultClientScopes": [
"web-origins",
"role_list",
"profile",
"roles",
"email"
],
"optionalClientScopes": [
"address",
"phone",
"offline_access",
"microprofile-jwt"
],
"access": {
"view": true,
"configure": true,
"manage": true
}
}
EOF
Créer des utilisateurs
Nous créons les utilisateurs en lisant un fichier csv
avec le format suivant :
Nom, Prénom, nom d'utilisateur, email
Par conséquent, dans votre répertoire kc_config
(EC2 ou Docker Container) créez un fichier csv
avec les informations de chaque utilisateur.
Note : Consultez User and group limits et assurez-vous que vous ne dépassez pas ces limites.
Voici un exemple :
cat <<EOF > users_list.csv
Tobias, CHAVARRIA, user01, user01@example.com
Albert, KONRAD, user02, user02@example.com
Stephan, BAUM, user03, user03@example.com
EOF
Une fois cela fait, nous créons les utilisateurs en utilisant les scripts suivants :
# Définir le nom du fichier csv
export USERS_CSV_FILE=users_list.csv
# Définir le mot de passe initial
export USERS_INITIAL_PASS="Pa55w0rd"
# Fonction : Créer un utilisateur et définir le mot de passe dans un REALM
kc_create_user() {
firstname=$1
lastname=$2
username=$3
email=$4
kcadm.sh create users -r $REALM \
-s username=$username \
-s email=$email \
-s firstName=$firstname \
-s lastName=$lastname \
-s enabled=true
kc_set_password $username $USERS_INITIAL_PASS
}
# Fonction : Définir un mot de passe pour un nom d'utilisateur donné dans un REALM
kc_set_password() {
username="$1"
initial_pass="$2"
kcadm.sh set-password \
-r $REALM \
--username $username --new-password $initial_pass
}
# Fonction : Lire et créer des utilisateurs en utilisant un fichier CSV comme source.
# - Format du fichier CSV : "prénom, nom, nom d'utilisateur, email, mot de passe"
import_users() {
while read -r line; do
IFS=',' read -ra arr <<< "$line"
kc_create_user ${arr[0]} ${arr[1]} ${arr[2]} ${arr[3]}
done < "$USERS_CSV_FILE"
}
# Enfin, nous importons les utilisateurs
import_users $USERS_CSV_FILE
Créer un groupe et ajouter des utilisateurs
Dans cette étape, nous allons créer un groupe et ajouter TOUS les utilisateurs existants sur le domaine donné dans ce groupe.
# Définir le nom du groupe
export GROUP_NAME="adaltas-students"
# Définir le fichier de liste d'identification des utilisateurs
export USERS_ID_LIST=users_list
# Créer le groupe
kcadm.sh create groups -r $REALM -s name=$GROUP_NAME
# Obtenir l'ID du groupe
export GROUP_ID=$(kcadm.sh get groups -r $REALM | grep -o '"id" : "[^"]*' | grep -o '[^"]*$')
# Exporter TOUS les identifiants dans le fichier USERS_ID_LIST
kcadm.sh get users -r $REALM | grep -o '"id" : "[^"]*"' | grep -o '[^"]*$' >> $USERS_ID_LIST
# Fonction : Ajouter un utilisateur (USER_ID) à un groupe donné (GROUP_ID)
kc_add_group() {
userid="$1"
groupid="$2"
kcadm.sh update users/$userid/groups/$groupid \
-r $REALM \
-s realm=$REALM \
-s userId=$userid \
-s groupId=$groupid \
-n
}
#Fonction : Ajouter des utilisateurs à un groupe en utilisant une liste (USERS_ID_LIST) comme source
add_users_group() {
n=1
while read -r userid; do
# lecture de chaque ligne
read -ra arr <<< "$userid"
echo "Updating user: $userid"
n=$((n+1))
kc_add_group $userid $GROUP_ID
done < $USERS_ID_LIST
}
# Enfin, nous ajoutons TOUS les utilisateurs au groupe
add_users_group $USERS_ID_LIST
Une fois la configuration effectuée, les utilisateurs peuvent utiliser la page de connexion suivante pour accéder à la console Cloudera :
http://<ec2_public_ip>:8080/realms/<realm>/protocol/saml/clients/cdp-sso
Pour une configuration supplémentaire ou une révision, vous pouvez également accéder à l’interface web de Keycloak ici :
http://<ec2_public_ip>:8080
Étape suivante : configuration des permissions et des politiques Ranger
À ce stade, Keycloak a été configuré comme fournisseur d’identité pour CDP et nous avons créé notre groupe d’utilisateurs.
Il reste encore une couche de configuration nécessaire dans le processus d’accueil des utilisateurs. Dans le chapitre suivant, nous allons montrer comment configurer les autorisations et les politiques nécessaires pour permettre aux utilisateurs d’utiliser notre architecture de bout en bout.