Designer Cloud et EMR serverless dans AWS
Suivez ce guide pour déployer le module Designer Cloud pour le traitement des données privé AWS.
Condition préalable
Avant de déployer le module Designer Cloud, vous devez effectuer les étapes suivantes sur la page Configurer un compte AWS et un VPC pour les données privées…
Un VPC dédié à Alteryx One Platform a été configuré comme indiqué dans la section Créer un VPC.
Avoir rattaché une politique de compte de service et IAM de base au compte de service, comme indiqué dans la section Configurer l'IAM.
Avoir déclenché avec succès le provisionnement du traitement des données privé, comme indiqué dans la section Déclencher le provisionnement de la gestion des données privées.
Configuration du compte
Étape 1 : Configurer l'IAM
Étape 1a : Créer une politique IAM Designer Cloud
Note
AAC_DesignerCloud_SA_Policy est un exemple de nom de politique. Vous pouvez choisir n'importe quel nom pour la politique, mais il doit commencer par AAC_DesignerCloud.
Vous devez créer une politique IAM personnalisée. Nommez-la AAC_DesignerCloud_SA_Policy et rattachez le document de politique suivant. Nous vous recommandons d'utiliser l'onglet JSON au lieu de l'éditeur visuel. Alteryx One a besoin d'autorisations * pour s'exécuter. Attendez-vous à recevoir des avertissements de sécurité lorsque vous créez la politique.
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "VisualEditor0",
"Effect": "Allow",
"Action": "iam:PassRole",
"Resource": "arn:aws:iam::*:role/*",
"Condition": {
"StringEqualsIfExists": {
"iam:PassedToService": [
"ec2.amazonaws.com",
"ec2.amazonaws.com.cn"
]
}
}
},
{
"Sid": "VisualEditor1",
"Effect": "Allow",
"Action": [
"eks:*",
"iam:CreateServiceLinkedRole",
"kms:CreateGrant",
"kms:Decrypt",
"kms:DescribeKey",
"kms:Encrypt",
"kms:GetKeyPolicy",
"kms:GetKeyRotationStatus",
"kms:ListGrants",
"kms:ListResourceTags",
"kms:ListRetirableGrants",
"kms:PutKeyPolicy",
"kms:RetireGrant",
"kms:RevokeGrant",
"kms:ScheduleKeyDeletion",
"kms:TagResource",
"kms:UntagResource"
],
"Resource": [
"arn:aws:eks:*:*:addon/*/*/*",
"arn:aws:eks:*:*:cluster/*",
"arn:aws:eks:*:*:nodegroup/*/*/*",
"arn:aws:eks:*:*:identityproviderconfig/*/*/*/*",
"arn:aws:eks:*:*:access-entry/*/*/*",
"arn:aws:kms:*:*:key/*",
"arn:aws:iam::*:role/*"
]
},
{
"Sid": "VisualEditor2",
"Effect": "Allow",
"Action": [
"iam:AttachRolePolicy",
"iam:CreateOpenIDConnectProvider",
"iam:CreatePolicy",
"iam:CreatePolicyVersion",
"iam:CreateRole",
"iam:DeleteOpenIDConnectProvider",
"iam:DeletePolicy",
"iam:DeletePolicyVersion",
"iam:DeleteRole",
"iam:DeleteRolePolicy",
"iam:DetachRolePolicy",
"iam:GetOpenIDConnectProvider",
"iam:GetPolicy",
"iam:GetPolicyVersion",
"iam:GetRole",
"iam:GetRolePolicy",
"iam:GetUser",
"iam:GetUserPolicy",
"iam:ListAttachedRolePolicies",
"iam:ListAttachedUserPolicies",
"iam:ListGroupsForUser",
"iam:ListInstanceProfilesForRole",
"iam:ListPolicyTags",
"iam:ListPolicyVersions",
"iam:ListRolePolicies",
"iam:PassRole",
"iam:PutRolePolicy",
"iam:TagOpenIDConnectProvider",
"iam:TagPolicy",
"iam:TagRole",
"iam:UntagOpenIDConnectProvider",
"iam:UntagPolicy",
"iam:UntagRole",
"iam:UpdateOpenIDConnectProviderThumbprint",
"iam:UpdateRole",
"iam:UpdateAssumeRolePolicy"
],
"Resource": [
"arn:aws:iam::*:policy/*",
"arn:aws:iam::*:oidc-provider/*",
"arn:aws:iam::*:user/*",
"arn:aws:iam::*:role/*"
]
},
{
"Sid": "VisualEditor3",
"Effect": "Allow",
"Action": [
"autoscaling:*",
"ec2:*",
"eks:CreateCluster",
"eks:ListClusters",
"eks:DescribeAddonVersions",
"elasticloadbalancing:*",
"iam:GetAccountName",
"iam:ListAccountAliases",
"iam:ListRoles",
"iam:CreateInstanceProfile",
"iam:DeleteInstanceProfile",
"iam:GetInstanceProfile",
"iam:TagInstanceProfile",
"iam:UntagInstanceProfile",
"iam:RemoveRoleFromInstanceProfile",
"iam:AddRoleToInstanceProfile",
"kms:CreateKey",
"logs:CreateLogGroup",
"logs:DeleteLogGroup",
"logs:DescribeLogGroups",
"logs:ListTagsLogGroup",
"logs:PutRetentionPolicy",
"logs:TagResource",
"logs:UntagResource",
"logs:TagLogGroup",
"logs:UntagLogGroup",
"logs:ListTagsForResource",
"networkmanager:Describe*",
"networkmanager:Get*",
"networkmanager:List*",
"s3:CreateBucket",
"s3:DeleteBucket",
"s3:DeleteBucketPolicy",
"s3:DeleteBucketWebsite",
"s3:DeleteObject",
"s3:DeleteObjectVersion",
"s3:DeleteObjectVersionTagging",
"s3:GetAccelerateConfiguration",
"s3:GetBucketAcl",
"s3:GetBucketCORS",
"s3:GetBucketLocation",
"s3:GetBucketLogging",
"s3:GetBucketObjectLockConfiguration",
"s3:GetBucketOwnershipControls",
"s3:GetBucketPolicy",
"s3:GetBucketPolicyStatus",
"s3:GetBucketPublicAccessBlock",
"s3:GetBucketRequestPayment",
"s3:GetBucketTagging",
"s3:GetBucketVersioning",
"s3:GetBucketWebsite",
"s3:GetEncryptionConfiguration",
"s3:GetLifecycleConfiguration",
"s3:GetObject",
"s3:GetObjectAcl",
"s3:GetObjectVersion",
"s3:GetObjectVersionAcl",
"s3:GetObjectVersionAttributes",
"s3:GetObjectVersionForReplication",
"s3:GetObjectVersionTagging",
"s3:GetObjectVersionTorrent",
"s3:GetReplicationConfiguration",
"s3:ListAllMyBuckets",
"s3:ListBucket",
"s3:ListBucketVersions",
"s3:PutAccelerateConfiguration",
"s3:PutBucketAcl",
"s3:PutBucketCORS",
"s3:PutBucketLogging",
"s3:PutBucketObjectLockConfiguration",
"s3:PutBucketOwnershipControls",
"s3:PutBucketPolicy",
"s3:PutBucketPublicAccessBlock",
"s3:PutBucketRequestPayment",
"s3:PutBucketTagging",
"s3:PutBucketVersioning",
"s3:PutBucketWebsite",
"s3:PutEncryptionConfiguration",
"s3:PutLifecycleConfiguration",
"s3:PutObject",
"s3:PutObjectAcl",
"s3:PutObjectVersionAcl",
"s3:PutObjectVersionTagging",
"sts:GetCallerIdentity",
"memorydb:CreateSubnetGroup",
"memorydb:CreateUser",
"memorydb:CreateAcl",
"memorydb:CreateCluster",
"memorydb:TagResource",
"memorydb:DescribeSubnetGroups",
"memorydb:DescribeUsers",
"memorydb:DescribeACLs",
"memorydb:DescribeClusters",
"memorydb:ListTags",
"memorydb:DeleteUser",
"memorydb:DeleteSubnetGroup",
"memorydb:DeleteAcl",
"memorydb:DeleteCluster",
"memorydb:UpdateAcl",
"memorydb:UpdateCluster",
"memorydb:UpdateSubnetGroup",
"memorydb:UpdateUser"
],
"Resource": "*"
},
{
"Sid": "VisualEditor4",
"Effect": "Allow",
"Action": "secretsmanager:*",
"Resource": "arn:aws:secretsmanager:*:*:secret:*"
}
]
}Étape 1b : Marquer la politique IAM
Marquez la politique IAM personnalisée créée à l'étape 1a.
Nom de la balise | Valeur |
|---|---|
AACResource | aac_sa_custom_policy |
Étape 1c : Rattacher la politique IAM
Rattachez la politique IAM AAC_DesignerCloud_SA_Policy au compte de service aac_automation_sa créé à la page Configurer un compte AWS et un VPC pour les données privées.
Étape 2 : Configurer le sous-réseau
Note
Designer Cloud partage une configuration de sous-réseau avec Machine Learning, Auto Insights et App Builder. Si vous déployez plusieurs de ces applications, vous n'avez besoin de configurer les sous-réseaux qu'une seule fois.
Designer Cloud dans un environnement de traitement de données privé, jusqu'à 5 groupes de sous-réseaux sont nécessaires. Chaque groupe contient 3 sous-réseaux individuels, chacun dans une zone de disponibilité différente.
Groupe eks_control (requis) : le plan de contrôle EKS utilise ce sous-réseau pour accepter les demandes d'exécution de tâche entrantes.
Groupe eks_node (requis) : le cluster EKS utilise ce sous-réseau pour exécuter des tâches logicielles Alteryx (par exemple, connectivité, conversion, traitement et publication).
Groupe public (requis) : ce groupe n'exécute aucun service, mais le groupe
eks_nodel'utilise pour les flux sortants du cluster.Groupe private (requis) : ce groupe exécute des services privés sur le traitement des données privé.
Groupe d'options (facultatif) : utilisez ce groupe si vous activez le traitement EMR dans votre environnement de traitement des données privé. Les services EMR ne s'exécutent pas dans le cluster, mais l'espace IP est nécessaire pour interagir avec les points de terminaison AWS serverless EMR.
Étape 2a : Créer des sous-réseaux dans le VPC
Configurez des sous-réseaux dans le VPC aac_vpc.
Créez des sous-réseaux et marquez-les conformément à l'exemple ci-dessous. Vous pouvez ajuster les CIDR et les valeurs de sous-réseau pour les adapter à votre architecture réseau.
Les grands espaces d'adressage sont conçus pour s'adapter à un cluster entièrement évolutif. Si nécessaire, vous pouvez choisir un espace d'adressage plus petit, mais vous risquez de rencontrer des problèmes de mise à l'échelle lors de charges de traitement importantes.
Important
Vous devez marquer les sous-réseaux avec le nom de la balise et la valeur de la balise comme indiqué dans le tableau.
CIDR | Nom du sous-réseau | Sous-réseau | AZ | Nom de la balise | Valeur de la balise | Remarque |
|---|---|---|---|---|---|---|
10.64.0.0/18 | eks_node | 10.64.0.0/21 | AZa | AACSubnet | eks_node | |
eks_node | 10.64.8.0/21 | AZb | AACSubnet | eks_node | ||
eks_node | 10.64.16.0/21 | AZc | AACSubnet | eks_node | ||
10.64.24.0/21 | SPARE | |||||
10.64.32.0/19 | SPARE (peut être configuré ultérieurement pour une mise à niveau bleu/vert) | |||||
10.10.0.0/21 | eks_control | 10.10.0.0/27 | AZa | AACSubnet | eks_control | |
eks_control | 10.10.0.32/27 | AZb | AACSubnet | eks_control | ||
eks_control | 10.10.0.64/27 | AZc | AACSubnet | eks_control | ||
10.10.0.96/27 | SPARE | |||||
publique | 10.10.0.128/27 | AZa | AACSubnet | publique | ||
publique | 10.10.0.160/27 | AZb | AACSubnet | publique | ||
publique | 10.10.0.192/27 | AZc | AACSubnet | publique | ||
10.10.0.224/27 | SPARE | |||||
privé | 10.10.1.0/25 | AZa | AACSubnet | privé | ||
privé | 10.10.1.128/25 | AZb | AACSubnet | privé | ||
privé | 10.10.2.0/25 | AZc | AACSubnet | privé | ||
10.10.1.128/25 | SPARE | |||||
option | 10.10.4.0/24 | AZa | AACSubnet | option | ||
option | 10.10.5.0/24 | AZa | AACSubnet | option | ||
option | 10.10.6.0/24 | AZa | AACSubnet | option | ||
10.10.7.0/24 | SPARE |
Étape 2b : Tables de routage des sous-réseaux
Créez la table de routage pour vos sous-réseaux.
Note
Cette table de routage est un exemple.
Nom du sous-réseau | Destination de routage | Cible | Commentaires |
|---|---|---|---|
eks_node | Bloc CIDR /18 Bloc CIDR /21 <id du préfixe s3> 0.0.0.0/0 | Locale Locale <id du point de terminaison vpce> <gateway id> | Configurez les mêmes routes vers les tables de routage des 3 sous-réseau AZ. |
eks_control | Bloc CIDR /18 Bloc CIDR /21 <id du préfixe s3> 0.0.0.0/0 | Locale Locale <id du point de terminaison vpce> <gateway id> | Configurez les mêmes routes vers les tables de routage des 3 sous-réseau AZ. |
publique | Bloc CIDR /18 Bloc CIDR /21 0.0.0.0/0 | Locale Locale <gateway id> | Configurez les mêmes routes vers les tables de routage des 3 sous-réseau AZ. |
privé | Bloc CIDR /18 Bloc CIDR /21 <id du préfixe s3> 0.0.0.0/0 | Locale Locale <id du point de terminaison vpce> <gateway id> | Configurez les mêmes routes vers les tables de routage des 3 sous-réseau AZ. 0.0.0.0/0 devrait sortir vers le réseau public. |
option | Bloc CIDR /18 Bloc CIDR /21 <id du préfixe s3> 0.0.0.0/0 | local local <id du point de terminaison vpce> <gateway id> | Configurez les mêmes routes vers les tables de routage des 3 sous-réseau AZ. 0.0.0.0/0 devrait sortir vers le réseau public. |
Note
Votre <gateway id> pourrait correspondre à une passerelle NAT de zone ayant été créée via AZ ou à une passerelle de transit, en fonction de votre architecture réseau. S'il s'agit d'une passerelle NAT, créez une passerelle NAT via AZ pour les sous-réseaux publics.
Traitement des données privées
Attention
La modification ou la suppression de ressources de cloud public provisionnées par Alteryx One après la configuration de gestion des données privées peut entraîner des incohérences. Ces incohérences peuvent causer des erreurs lors de l'exécution de la tâche ou lors du désapprovisionnement de la configuration de gestion des données privées.
Étape 1 : Déclencher le déploiement Designer Cloud
Le provisionnement de Designer Cloud est déclenché à partir de la console d'administration dans Alteryx One. Vous devez disposer des privilèges Admin de l'espace de travail dans un espace de travail pour pouvoir le voir.
Depuis la page d'accueil Alteryx One, sélectionnez l'icône en forme de cercle en haut à droite avec vos initiales. Sélectionnez Console d'administration dans le menu.
Dans le menu de navigation de gauche, sélectionnez Gestion des données privées.
Cochez la case Designer Cloud, puis sélectionnez Mettre à jour.
Sélectionner Mettre à jour déclenche le déploiement du cluster et des ressources dans le compte AWS. Cela permet d'exécuter une série de contrôles de validation afin de vérifier la configuration correcte du compte AWS.
Note
Le processus de provisionnement dure environ 35 à 40 minutes.
Une fois le provisionnement terminé, vous pouvez afficher les ressources créées (par exemple, les instances EC2 et les groupes de nœuds) via la console AWS. Il est essentiel de ne pas les modifier vous-même. Les modifications manuelles peuvent entraîner des problèmes avec le fonctionnement du traitement des données privé.
Étape 2 : Ajouter la relation de confiance du rôle personnalisé
Note
Cette étape n'est nécessaire que si vous avez utilisé un rôle inter-comptes pour les autorisations lorsque vous avez configuré le stockage de données privées. Si vous avez utilisé une clé d'accès pour cette étape, vous pouvez ignorer cette étape.
Important
Vous devez attendre la fin de l'étape 1 avant de poursuivre cette étape.
Si votre stockage de données privées utilise un rôle inter-comptes, pour que votre nouvel environnement de traitement des données privé puisse lire/écrire à partir de votre stockage de données privées, vous devez mettre à jour ce rôle pour ajouter une relation de confiance à votre nouveau rôle de cluster Kubernetes :
{
"Sid": "",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::<accountid>:role/aac-<xxxx-xxxxxxxxxxxx>-cluster-role"
},
"Action": "sts:AssumeRole"
}Note
Remplacez l'ID principal AWS par l'ARN du rôle IAM créé par le processus de provisionnement de gestion des données privées.
<accountid> : numéro de compte AWS où la gestion de l'environnement de traitement des données privé a été provisionnée.
<xxxx-xxxxxxxxxxxx> : 2 derniers segments de l'ID d'environnement de traitement des données privé. Vous pouvez localiser cet ID dans l'interface utilisateur Admin une fois que l'environnement de traitement des données privé a été provisionné avec succès.
Exemple de scénario :
ID de compte : 123456789012
ID de l'environnement de traitement des données privé : b2a65fbd-95dc-490a-b69b-a1dc92df224e
ARN du rôle : arn:aws:iam::123456789012:role/aac-b69b-a1dc92df224e-cluster-role
Pour plus d'informations, consultez la page https://docs.aws.amazon.com/directoryservice/latest/admin-guide/edit_trust.html.
Étape 3 : Mettre à jour la politique de clé KMS
Une fois que vous avez réussi à créer le traitement des données privé, un rôle personnalisé appelé credential-service-role est ajouté à votre compte. Ce rôle permet au compte de service d'informations d'identification Kubernetes de récupérer des informations d'identification d'accès aux données privées à partir du coffre-fort de clés.
À présent, mettez à jour la politique de la clé KMS, créée à l'Configurer un compte AWS et un VPC pour les données privéesétape 5 : Créer une clé symétrique pour le coffre-fort sécurisé, pour accorder au rôle personnalisé credential-service-role des autorisations personnalisées.
Accédez à la section Services de gestion des clés et sélectionnez la clé créée dans Configurer un compte AWS et un VPC pour les données privées.
Sélectionnez Politique de clé et sélectionnez Modifier.
Supprimez l'autorisation par défaut et mettez-la à jour avec :
{ "Version": "2012-10-17", "Id": "key-consolepolicy-3", "Statement": [ { "Sid": "Enable IAM User Permissions", "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::<account id>:root" }, "Action": "kms:*", "Resource": "*" }, { "Sid": "Allow use of the key", "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::<account id>:role/credential-service-role" }, "Action": [ "kms:Encrypt", "kms:Decrypt", "kms:ReEncrypt*", "kms:GenerateDataKey*", "kms:DescribeKey" ], "Resource": "*" } ] }Note
<accountID>est le numéro de compte AWS où la gestion de l'environnement de traitement des données privé a été provisionnée.Sélectionnez Enregistrer les modifications.
Étape 4 : EMR serverless (facultatif)
Configurez EMR serverless si vous utilisez le traitement Spark/EMR.
Activer EMR
Connectez-vous à Alteryx One.
Dans le menu Profil, sélectionnez Console d'administration.
Dans le panneau de navigation de gauche, sélectionnez Gestion des données privées.
Sélectionnez Traitement Spark (EMR).
Sélectionnez Mettre à jour.
Mettre à jour le rôle personnalisé créé pour la connexion S3
Ajoutez la politique personnalisée et le rôle personnalisé à partir de AWS S3 en tant que stockage de données privées avec les autorisations et les relations de confiance suivantes pour EMR serverless :
Ajouter un document de politique personnalisé
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "EMRServerlessAccess",
"Effect": "Allow",
"Action": [
"emr-serverless:CreateApplication",
"emr-serverless:UpdateApplication",
"emr-serverless:DeleteApplication",
"emr-serverless:ListApplications",
"emr-serverless:GetApplication",
"emr-serverless:StartApplication",
"emr-serverless:StopApplication",
"emr-serverless:StartJobRun",
"emr-serverless:CancelJobRun",
"emr-serverless:ListJobRuns",
"emr-serverless:GetJobRun"
],
"Resource": "*"
},
{
"Sid": "AllowNetworkInterfaceCreationViaEMRServerless",
"Effect": "Allow",
"Action": "ec2:CreateNetworkInterface",
"Resource": [
"arn:aws:ec2:*:*:network-interface/*",
"arn:aws:ec2:*:*:security-group/*",
"arn:aws:ec2:*:*:subnet/*"
],
"Condition": {
"StringEquals": {
"aws:CalledViaLast": "ops.emr-serverless.amazonaws.com"
}
}
},
{
"Sid":"AllowEMRServerlessServiceLinkedRoleCreation",
"Effect":"Allow",
"Action":"iam:CreateServiceLinkedRole",
"Resource":"arn:aws:iam:::role/aws-service-role/ops.emr-serverless.amazonaws.com/AWSServiceRoleForAmazonEMRServerless"
},
{
"Sid": "AllowPassingRuntimeRole",
"Effect": "Allow",
"Action": "iam:PassRole",
"Resource": "arn:aws:iam:::role/aac--emr-serverless-spark-execution",
"Condition": {
"StringLike": {
"iam:PassedToService": "emr-serverless.amazonaws.com"
}
}
},
{
"Sid": "S3ResourceBucketAccess",
"Effect": "Allow",
"Action": [
"s3:PutObject",
"s3:GetObject",
"s3:ListBucket",
"s3:DeleteObject"
],
"Resource": [
"arn:aws:s3:::aac--emr-logs",
"arn:aws:s3:::aac--emr-logs/*"
]
}
]
}Ajouter la relation de confiance du rôle personnalisé
{
"Sid": "",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam:::role/aac--emr-serverless-spark-execution"
},
"Action": "sts:AssumeRole"
},
{
"Sid": "",
"Effect": "Allow",
"Principal": {
"Service": "emr-serverless.amazonaws.com"
},
"Action": "sts:AssumeRole"
}Note
Lorsque vous supprimez la gestion des données privées, AWS remplace la relation de confiance de l'ARN aac-<xxxx-xxxxxxxxxxxxxx>-cluster-role par une clé d'accès. Vous devez également supprimer la relation de confiance de l'interface utilisateur.
Note
Remplacez l'ID principal AWS par l'ARN du rôle IAM créé par le processus de provisionnement de gestion des données privées.
<accountid> : numéro de compte AWS où la gestion de l'environnement de traitement des données privé a été provisionnée.
<xxxx-xxxxxxxxxxxx> : 2 derniers segments de l'ID d'environnement de traitement des données privé. Vous pouvez localiser cet ID dans l'interface utilisateur Admin une fois que l'environnement de traitement des données privé a été provisionné avec succès.
Exemple de scénario :
ID de compte : 123456789012
ID de l'environnement de traitement des données privé : b2a65fbd-95dc-490a-b69b-a1dc92df224e
ARN du rôle : arn:aws:iam::123456789012:role/aac-b69b-a1dc92df224e-emr-serverless-spark-execution
ARN S3 : arn:aws:s3:::aac-aac-b69b-a1dc92df224e-emr-logs