Les secrets Key Management Service (KMS) sont des ressources spécifiques à une région. Si vous recevez une notification de migration pour une région, migrez vos secrets vers la région de destination dès que possible afin d'éviter toute interruption de service. La méthode de migration dépend du type de secret.
| Type de secret | Migration requise | Approche |
|---|---|---|
| Secret générique (dans une instance KMS) | Oui | Migration par sauvegarde et restauration |
| Secret générique (en dehors d'une instance KMS) | Oui | Recréez le secret dans la région de destination à l'aide de l'API |
| Secret RAM | Migration non prise en charge — suppression et recréation | Supprimez-le dans la région source, puis créez-le dans la région de destination |
| Secret ApsaraDB RDS | Non | Les instances ApsaraDB RDS sont spécifiques à une région ; les secrets suivent automatiquement |
| Secret ECS | Non | Les instances Elastic Compute Service (ECS) sont spécifiques à une région ; les secrets suivent automatiquement |
Secret générique
Contraintes
Pendant la migration, n'effectuez aucune opération sur le secret dans la région source tant que la migration n'est pas terminée et que vous n'avez pas supprimé le secret source. Par exemple, ne modifiez pas les métadonnées du secret et ne créez pas de nouvelle version de secret (par exemple, n'appelez pas
PutSecretValue).Après la migration, les horodatages de création du secret et de ses versions différeront entre la région source et la région de destination. Cela n'affecte pas vos services.
Migrer un secret générique dans une instance KMS
Si votre secret générique a été créé au sein d'une instance KMS, migrez-le via la sauvegarde et la restauration. Pour plus de détails, consultez Sauvegardes.
Migrer un secret générique en dehors d'une instance KMS
Dans l'ancienne version de KMS, vous pouviez créer un secret générique sans acheter d'instance KMS. Ce type de secret est considéré comme « en dehors d'une instance KMS ». Avec KMS 3.0, vous devez acheter une instance KMS avant de créer un secret générique.
Suivez la procédure ci-dessous pour recréer le secret dans la région de destination via des appels d'API.
Étape 1 : Interrogez et enregistrez les détails du secret dans la région source
Appelez les API suivantes dans la région source pour récupérer toutes les informations nécessaires à la recréation du secret :
| API | Paramètre clé | Objectif |
|---|---|---|
DescribeSecret |
Définissez FetchTags sur true |
Récupérez les métadonnées du secret (nom, type, tags, description, configuration étendue) |
ListSecretVersionIds |
Définissez IncludeDeprecated sur true |
Récupérez toutes les versions de secret, y compris celles qui sont obsolètes |
GetSecretValue |
Appelez une fois par version | Récupérez la valeur du secret et le type de valeur pour chaque version |
Les VersionIds dans la réponse de ListSecretVersionIds ne sont pas triés par heure de création. Triez-les localement avant de continuer.
Par exemple, si ListSecretVersionIds renvoie trois versions, triez-les par heure de création :
| Version | Créée le | Étape |
|---|---|---|
| v1 | 1er janvier 2023 | 001 (version initiale) |
| v2 | 1er mai 2023 | ACSPrevious |
| v3 | 1er novembre 2023 | ACSCurrent |
Étape 2 : Migrez votre application vers la région de destination
Déplacez votre application vers la région de destination.
-
Créez un identifiant pour l'application dans la région de destination :
Si vous utilisez une paire AccessKey d'un utilisateur ou d'un rôle Resource Access Management (RAM) : Créez un utilisateur ou un rôle RAM dans la région de destination et attachez la politique
AliyunKMSSecretAdminAccess. Consultez Créer un utilisateur RAM et accorder des autorisations à l'utilisateur RAM et Créer un rôle RAM et attacher les politiques requises au rôle.Si vous utilisez une clé client d'un point d'accès applicatif (AAP) : Achetez d'abord une instance KMS, puis créez une clé client dans la région de destination. Consultez Créer un AAP.
-
Mettez à jour les paramètres d'endpoint et d'identifiant dans votre application.
Les endpoints KMS et les endpoints d'instance KMS sont différents. Configurez l'endpoint en fonction du SDK que vous utilisez. Pour plus de détails, consultez Références SDK.
Étape 3 : Créez le secret dans la région de destination
Achetez une instance KMS dans la région de destination. Consultez Sélection d'instance et Acheter et activer une instance KMS.
Créez une clé dans l'instance KMS pour chiffrer le secret. Consultez Prise en main de la gestion des clés.
-
Appelez les API suivantes pour recréer le secret avec des métadonnées, des versions et des valeurs identiques :
API Ce qu'il faut définir CreateSecretUtilisez les valeurs issues de DescribeSecretpoursecretName,secretType,Tags,DescriptionetExtendedConfig. PourVersionId, utilisez la version initiale (v1 dans cet exemple). PourSecretDataetSecretDataType, utilisez les valeurs issues deGetSecretValuepour la version initiale.PutSecretValueStockez chaque version restante. Dans cet exemple, appelez l'API une fois pour v2 et une fois pour v3. UpdateSecretVersionStageDéfinissez l'étape pour chaque version. Dans cet exemple : v1 → 001, v2 →ACSPrevious, v3 →ACSCurrent. Appelez
DescribeSecretdans les deux régions et confirmez que les informations concernant le secret sont identiques.
Étape 4 : Vérifiez votre application
Testez votre application dans la région de destination pour confirmer qu'elle peut accéder au secret et s'exécute comme prévu.
Étape 5 : Supprimez le secret dans la région source
Une fois que vous avez confirmé que l'application fonctionne correctement dans la région de destination, supprimez le secret dans la région source. Consultez Gérer et utiliser des secrets génériques.
Utilisez ActionTrail pour vérifier les récents appels d'API effectués sur un secret avant de le supprimer. Les événements liés aux secrets incluentGetSecretValue,DescribeSecret,ListSecretVersionIds,PutSecretValue,UpdateSecret,UpdateSecretVersionStage,UpdateSecretRotationPolicyetRestoreSecret. Consultez Utiliser ActionTrail pour interroger les événements KMS et Auditer les événements de KMS.
Secret RAM
La migration n'est pas prise en charge. Un utilisateur RAM ne peut posséder qu'un seul secret RAM dans KMS. Pour déplacer un secret RAM vers une nouvelle région, supprimez-le dans la région source et créez-en un nouveau dans la région de destination.
Avant de supprimer un secret RAM de KMS, assurez-vous qu'il n'est plus utilisé. La suppression du secret RAM depuis KMS ne supprime pas la paire AccessKey associée.
Secret ApsaraDB RDS
Aucune migration n'est requise. Les instances ApsaraDB RDS sont des ressources spécifiques à une région, de sorte que les secrets associés n'ont pas besoin d'être migrés séparément.
Secret ECS
Aucune migration n'est requise. Les instances Elastic Compute Service (ECS) sont des ressources spécifiques à une région, de sorte que les secrets associés n'ont pas besoin d'être migrés séparément.