Tutoriel : Mettre en place une authentification multi-facteurs pour votre compte

Pour mettre en place une authentification multi-facteurs (MFA) sur votre compte OUTSCALE :

Vous devez importer une autorité de certification (CA) qui servira d’ancre de confiance dans une chaîne de confiance.
Vous devez ensuite configurer vos règles d’accès API pour obliger toutes les requêtes API à fournir un certificat client. Si ce certificat client est stocké sur un périphérique physique distinct, tel qu’une carte à puce, il constitue un facteur de possession et donc un second facteur d’authentification (par rapport à vos access keys, facteur de connaissance, qui constituent le premier facteur d’authentification).

Les cartes à puce doivent se conformer au standard Personal Identity Verification (PIV).
Vous pouvez alors activer une session de confiance avec votre politique d’accès API afin de simplifier votre accès aux API. Si vous utilisez Cockpit v2-beta, une session de confiance est automatiquement simulée pour vous.

Faites attention lorsque vous suivez ce tutoriel. Une mauvaise configuration de vos CA, certificat client et règles d’accès API peuvent entraîner un blocage de votre compte.

Cette procédure utilise uniquement OSC CLI. Une fois la MFA mise en place pour votre compte OUTSCALE, vous pouvez configurer un certificat client pour d’autres interfaces comme Cockpit v2-beta ou Terraform.

Générer une CA

Si vous possédez déjà une CA au format PEM, vous pouvez sauter cette section.

Générez une clé privée de CA :
```
$ openssl genrsa -aes256 -out ca-key.pem 4096
```
Il est recommandé de protéger votre clé privée de CA par une phrase de passe.

Avec la clé privée de CA, générez un certificat de CA :

$ openssl req -new \
    -x509 \
    -days 365 \
    -key ca-key.pem \
    -out ca-certificate.pem \
    -config <(cat /etc/ssl/openssl.cnf <(echo -e "[ext]\nbasicConstraints = critical,CA:TRUE,pathlen:1")) \
    -extensions ext

Cette commande contient une configuration spécifique de "contraintes de base", nécessaire pour que le certificat de CA soit accepté dans le Cloud OUTSCALE.
Cette commande génère via le paramètre -days 365 un certificat de CA valide pendant un an, mais vous pouvez aussi spécifier une valeur différente. Pour en savoir plus, voir le site officiel de la commande OpenSSL.

Votre clé privée de CA est enregistrée sous ca-key.pem et votre certificat de CA sous ca-certificate.pem.

Importer votre CA

Avant de commencer : Installez OSC CLI. Pour en savoir plus, voir Installer et configurer OSC CLI.

Importez votre certificat de CA avec OSC CLI :

$ osc-cli api CreateCa \
    --Description "My company CA" \
    --CaPem="$(cat ca-certificate.pem)"

Exemple de réponse

"Ca": {
    "CaFingerprint": "FINGERPRINT",
    "CaId": "ca-12345678",
    "Description": "My company CA"
}

Pour vérifier la bonne transmission de votre CA, vous pouvez comparer l’empreinte de la réponse ci-dessus avec l’empreinte générée par cette commande :

$ openssl x509 -in ca-certificate.pem -noout -sha1 -fingerprint | awk '{gsub(/.*=/, ""); gsub(":",""); print tolower($0)}'

Votre certificat de CA est maintenant disponible dans votre compte OUTSCALE.

Configurer vos règles d’accès API

Créez une règle d’accès API autorisant uniquement les requêtes API qui fournissent un certificat client :

$ osc-cli api CreateApiAccessRule \
    --CaIds '["ca-12345678"]' \
    --Description "Allow access with certificates validated by my CA"

Contrairement à Cockpit v2-beta, Cockpit v1 ne supporte pas les certificats clients. Par conséquent, si vous sécurisez votre compte avec une règle d’accès API contenant une CA comme critère, vous ne pourrez plus accéder à Cockpit v1. Pour en savoir plus, voir À propos des règles d’accès API.

(Optionnel) Créez une règle d’accès API autorisant uniquement les requêtes API qui proviennent d’une IP à laquelle vous avez accès :
```
$ osc-cli api CreateApiAccessRule \
    --IpRanges '["192.0.2.0/32"]' \
    --Description "Backup access if certificate access fails"
```
Si possible, utilisez une IP différente de votre IP actuelle, par exemple une IP de VPN, afin de tester parfaitement l’accès.

Listez les ID de toutes vos règles d’accès API :

$ osc-cli api ReadApiAccessRules

Exemple de réponse

    "ApiAccessRules": [
        {
            "ApiAccessRuleId": "aar-11111111",
            "CaIds": [],
            "Cns": [],
            "Description": "Allows all IPv4 domain",
            "IpRanges": [
                "0.0.0.0/0"
            ]
        },
        {
            "ApiAccessRuleId": "aar-22222222",
            "CaIds": [],
            "Cns": [],
            "Description": "Allows Outscale Cockpit of this region",
            "IpRanges": [
                "46.231.144.177/32"
            ]
        }
        {
            "ApiAccessRuleId": "aar-33333333",
            "CaIds": [
                "ca-12345678"
            ],
            "Cns": [],
            "Description": "Allow access with certificates validated by my CA",
            "IpRanges": []
        }
        {
            "ApiAccessRuleId": "aar-44444444",
            "CaIds": [],
            "Cns": [],
            "Description": "Backup access if certificate access fails",
            "IpRanges": [
                "192.0.2.0/32"
            ]
        }
    ]

Par défaut, chaque compte possède les règles d’accès API suivantes :

L’accès global est autorisé (0.0.0.0/0).
L’accès depuis l’interface web Cockpit v1 de la Région du compte est autorisée.

Supprimez la règle d’accès API autorisant l’accès global :

$ osc-cli api DeleteApiAccessRule --ApiAccessRuleId "aar-11111111"

Générer un certificat client

Pour une MFA renforcée, vous pouvez utiliser un périphérique physique distinct, tel qu’une carte à puce, pour générer et stocker vos certificats clients.

Générez une clé privée de certificat et une demande de certificat :
```
$ openssl req -new \
    -sha256 \
    -nodes \
    -newkey rsa:2048 \
    -keyout client-key.pem \
    -out client-certificate.csr
```
Si vous utilisez un périphérique physique distinct, adaptez la valeur du paramètre newkey aux spécifications de votre périphérique.

Votre clé privée de certificat est enregistrée sous client-key.pem et votre demande de certificat sous client-certificate.csr.

Avec les fichiers ci-dessus, générez un certificat client signé par votre CA :

$ openssl x509 -req \
    -sha256 \
    -days 365 \
    -CAkey ca-key.pem \
    -CA ca-certificate.pem \
    -CAcreateserial \
    -in client-certificate.csr \
    -out client-certificate.pem \
    -extfile <(echo "extendedKeyUsage = clientAuth")

Cette commande génère via le paramètre -days 365 un certificat client valide pendant un an, mais vous pouvez aussi spécifier une valeur différente. Pour en savoir plus, voir le site officiel de la commande OpenSSL.

Votre certificat client est enregistré sous client-certificate.pem.

Configurer votre accès

Configurer votre accès pour OSC CLI

Pour configurer OSC CLI de sorte à utiliser votre certificat client, ajoutez un profil (nommé par exemple secure) dans votre fichier .osc_sdk/config.json :

.osc_sdk/config.json

{
    "default": {
        "access_key": "ACCESSKEY",
        "secret_key": "SECRETKEY",
        "host": "outscale.com",
        "https": true,
        "method": "POST",
        "region_name": "eu-west-2"
    },
    "secure": {
        "access_key": "ACCESSKEY",
        "secret_key": "SECRETKEY",
        "host": "outscale.com",
        "https": true,
        "method": "POST",
        "region_name": "eu-west-2",
        "client_certificate": [
            "/PATHTO/client-certificate.pem",
            "/PATHTO/client-key.pem"
        ]
    }
}

Remplacez ACCESSKEY, SECRETKEY, eu-west-2, et /PATHTO/ avec les valeurs adéquates.

Testez votre profil secure en exécutant une commande OSC CLI quelconque :
```
$ osc-cli api ReadVms --profile "secure"
```

Si votre profil secure fonctionne correctement, vous pouvez supprimer la règle d’accès API autorisant l’accès depuis Cockpit v1, ainsi que celle autorisant une IP à laquelle vous avez l’accès :

$ osc-cli api DeleteApiAccessRule --profile "secure" --ApiAccessRuleId "aar-22222222"
$ osc-cli api DeleteApiAccessRule --profile "secure" --ApiAccessRuleId "aar-44444444"

Votre compte est maintenant configuré pour autoriser uniquement les requêtes API qui fournissent un certificat client.

Si vous ne pouvez plus réaliser d’actions sur votre compte OUTSCALE via les règles en place, vous devez contacter l’équipe Support pour y avoir accès à nouveau. Pour en savoir plus, voir Support technique.

Configurer votre accès pour Cockpit v2-beta

Convertissez votre certificat client au format PKCS 12 en utilisant la commande suivante :

$ openssl pkcs12 \
    -inkey client-key.pem \
    -in client-certificate.pem \
    -export -out web-client-certificate.p12

Testez votre accès en vous connectant à Cockpit v2-beta. Pour en savoir plus, voir Se connecter et déconnecter d’une session de confiance.

Si vous parvenez à vous connecter, vous pouvez supprimer la règle d’accès API autorisant l’accès depuis Cockpit v1, ainsi que celle autorisant une IP à laquelle vous avez l’accès :

$ osc-cli api DeleteApiAccessRule --profile "secure" --ApiAccessRuleId "aar-22222222"
$ osc-cli api DeleteApiAccessRule --profile "secure" --ApiAccessRuleId "aar-44444444"

Votre compte est maintenant configuré pour autoriser uniquement les requêtes API qui fournissent un certificat client, y compris celles provenant de Cockpit v2-beta.

Activer une session de confiance

Si vous utilisez Cockpit v2-beta, vous n’avez pas besoin d’activer une session de confiance car Cockpit v2-beta en simule automatiquement une pour vous.

Récupérez les ID de toutes vos access keys :

$ osc-cli api ReadAccessKeys --profile "secure"

Exemple de réponse

"AccessKeys": [
    {
        "AccessKeyId": "AAAAAAAAAAAAAAAA",
        "CreationDate": "YYYY-MM-DDThh:mm:ss.000Z",
        "LastModificationDate": "YYYY-MM-DDThh:mm:ss.000Z",
        "State": "ACTIVE"
    },
    {
        "AccessKeyId": "BBBBBBBBBBBBBBBB",
        "CreationDate": "YYYY-MM-DDThh:mm:ss.000Z",
        "LastModificationDate": "YYYY-MM-DDThh:mm:ss.000Z",
        "State": "ACTIVE"
    }
]

Définissez des dates d’expiration pour toutes vos access keys :

$ osc-cli api UpdateAccessKey \
    --profile "secure" \
    --AccessKeyId "AAAAAAAAAAAAAAAA" \
    --State "ACTIVE" \
    --ExpirationDate "20XX-XX-XXTXX:XX:XXZ"

$ osc-cli api UpdateAccessKey \
    --profile "secure" \
    --AccessKeyId "BBBBBBBBBBBBBBBB" \
    --State "ACTIVE" \
    --ExpirationDate "20XX-XX-XXTXX:XX:XXZ"

Toutes vos access keys ont maintenant des durées de vie finies.

Les access keys des utilisateurs EIM ne peuvent pas avoir de date d’expiration. Si vous avez des utilisateurs EIM dans votre compte, vous devez supprimer leurs access keys. Pour en savoir plus, voir Supprimer une access key EIM.

Pour activer une session de confiance, modifiez votre politique d’accès API :

$ osc-cli api UpdateApiAccessPolicy \
    --profile "secure" \
    --MaxAccessKeyExpirationSeconds XXXXXX \
    --RequireTrustedEnv True

La valeur du paramètre MaxAccessKeyExpirationSeconds doit être supérieure ou égale à chacune des durées de vie restantes de vos access keys.
Vos access keys peuvent expirer avant la fin de votre session de confiance. Assurez-vous de les renouveler lorsque nécessaire.
Il peut y avoir un léger délai entre la réponse de la commande et l’application effective de la session de confiance.

Votre session de confiance est maintenant activée. Vous n’avez plus besoin de fournir votre certificat client, jusqu’à ce que vous décidiez de désactiver la session de confiance, sauf pour certaines actions spécifiques. Pour en savoir plus, voir À propos de votre politique d’accès API > Portée d’une session de confiance.

Pages connexes

Méthodes API correspondantes

API OUTSCALE