Amazon Redshift ne prendra plus en charge la création de nouveaux Python à UDFs partir du patch 198. UDFs Le Python existant continuera de fonctionner jusqu'au 30 juin 2026. Pour plus d’informations, consultez le [ billet de blog ](https://aws.amazon.com/blogs/big-data/amazon-redshift-python-user-defined-functions-will-reach-end-of-support-after-june-30-2026/). 

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

# Authentification d’une requête planifiée
<a name="query-editor-v2-schedule-query-authentication"></a>

Lorsque vous planifiez une requête, vous utilisez l'une des méthodes d'authentification suivantes lors de l'exécution SQL. Les entrées à effectuer dans l'éditeur de requête v2 varient en fonction de la méthode utilisée. Ces méthodes d'authentification sont prises en charge par l'API de données utilisée pour exécuter vos instructions SQL.

L'utilisateur ou le rôle de base de données utilisé pour exécuter la requête doit disposer des privilèges de base de données nécessaires. Par exemple, pour accorder des privilèges `IAMR:MyRedshiftQEv2Scheduler` à la table `mytable`, exécutez la commande SQL suivante.

```
GRANT all ON TABLE mytable TO "IAMR:MyRedshiftQEv2Scheduler";
```

Pour afficher la liste des utilisateurs de base de données de votre cluster ou groupe de travail, interrogez la vue système `PG_USER_INFO`.

**Note**  
 Tout groupe de travail Redshift sans serveur pour lequel vous planifiez des requêtes doit être balisé avec la clé `RedshiftDataFullAccess`. Pour plus d’informations, consultez [Autorisation de l’accès à l’API de données Amazon Redshift](data-api-access.md).  
Au lieu de baliser le groupe de travail, vous pouvez également ajouter une politique en ligne au rôle IAM (spécifié avec la planification) qui autorise `redshift-serverless:GetCredentials`. Par exemple :  

****  

```
{
    "Version":"2012-10-17",		 	 	 
    "Statement": [
        {
            "Sid": "UseTemporaryCredentialsForAllServerlessWorkgroups",
            "Effect": "Allow",
            "Action": "redshift-serverless:GetCredentials",
            "Resource": [
                "arn:aws:redshift-serverless:*:*:workgroup/*"
            ]
        }
    ]
}
```

**AWS Secrets Manager**  
Avec cette méthode, fournissez une valeur secrète pour le paramètre **secret-arn** qui est stocké dans AWS Secrets Manager. Ce secret contient des informations d’identification pour vous connecter à votre base de données. Vous avez peut-être créé un secret avec les informations d’identification appropriées lorsque vous avez créé votre cluster ou votre groupe de travail. Le secret doit être étiqueté avec la clé `RedshiftDataFullAccess`. Si la clé de balise n'est pas déjà présente, utilisez la AWS Secrets Manager console pour l'ajouter. Pour plus d’informations sur la création d’un secret, consultez [Création d’un secret pour les informations d’identification de connexion à une base de données](redshift-secrets-manager-integration-create.md).  
Pour plus d’informations sur les autorisations minimales, consultez [Création et gestion des secrets avec AWS Secrets Manager](https://docs.aws.amazon.com/secretsmanager/latest/userguide/managing-secrets.html) dans le *Guide de l’utilisateur AWS Secrets Manager *. 

**Informations d’identification temporaires**  
Avec cette méthode, indiquez le **Nom de la base de données** et l'**Utilisateur de la base de données** pour vous connecter à une base de données située dans un cluster. Vous devez simplement indiquer le **Nom de la base de données** au moment de vous connecter à une base de données d'un groupe de travail.  
Lorsque vous vous connectez à un cluster, la politique `AmazonRedshiftDataFullAccess` accorde à l'utilisateur de base de données nommé `redshift_data_api_user` une autorisation pour `redshift:GetClusterCredentials`. Si vous souhaitez utiliser un autre utilisateur de base de données pour exécuter l'instruction SQL, ajoutez une politique au rôle IAM attaché à votre cluster pour autoriser `redshift:GetClusterCredentials`. L’exemple de stratégie suivant autorise les utilisateurs de base de données `awsuser` et `myuser`.     
****  

```
{
    "Version":"2012-10-17",		 	 	 
    "Statement": [
        {
            "Sid": "UseTemporaryCredentialsForAllDbUsers",
            "Effect": "Allow",
            "Action": "redshift:GetClusterCredentials",
            "Resource": [
                "arn:aws:redshift:*:*:dbuser:*/awsuser",
                "arn:aws:redshift:*:*:dbuser:*/myuser"
            ]
        }
    ]
}
```