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.

Rotation des informations de connexion

Amazon MSK prend en charge la rotation des mots de passe uniquement, dans le cadre de laquelle un secret associé conserve un seul nom d'utilisateur et la rotation ne modifie que le mot de passe. Cela correspond à la stratégie de rotation mono-utilisateur de Secrets Manager. Une fois le mot de passe mis à jour transmis aux courtiers, les nouvelles tentatives d'authentification nécessitent le nouveau mot de passe et le mot de passe précédent cesse de s'authentifier.

Modifier un nom d'utilisateur dans un secret associé

Si le nom d'utilisateur est modifié dans un secret déjà associé à un cluster, Amazon MSK charge les nouvelles informations d'identification tandis que les informations d'identification précédemment mises en cache peuvent rester disponibles sur les courtiers. Cette disponibilité continue n'est pas une période de chevauchement prise en charge ou garantie pour la rotation des informations d'identification.

Amazon MSK ne fournit pas de période de conservation définie pour ces informations d'identification mises en cache. Il est donc impossible de se fier à leur disponibilité tout au long d'une transition client. Amazon MSK lit uniquement la AWSCURRENT version d'un secret associé et ne l'utilise pas AWSPREVIOUS comme deuxième identifiant actif. Une fois qu'un identifiant précédent est supprimé des courtiers, il ne peut pas être rechargé depuis Secrets Manager.

Remplacement d'un nom d'utilisateur

Pour remplacer un nom d'utilisateur sans la faille d'authentification causée par la dissociation et la réassociation du même secret, créez un secret distinct contenant le nouveau nom d'utilisateur et associez-le au cluster à l'aide de l'opération. BatchAssociateScramSecret

Configurez les ACL Kafka requises, attendez que les nouvelles informations d'identification se propagent, vérifiez qu'elles fonctionnent et migrez vos clients. Une fois la migration terminée, révoquez l'accès de l'utilisateur précédent et dissociez l'ancien secret à l'aide de l'BatchDisassociateScramSecretopération.

Cette approche permet de conserver les deux informations d'identification associées intentionnellement pendant la transition au lieu de dépendre d'une identification précédemment chargée qui reste entre les mains des courtiers.

Suppression des informations d'identification conservées

Vous pouvez utiliser la même approche progressive pour supprimer les informations d'identification conservées après la modification d'un nom d'utilisateur dans un secret qui était déjà associé à un cluster. Associez des secrets de remplacement et migrez vos clients avant de dissocier les secrets concernés.

La dissociation supprimera ensuite les informations d'identification actuelles et précédemment conservées associées à chaque ancien secret sans interrompre les clients qui ont migré vers les informations d'identification de remplacement.