Cette rubrique répond aux questions courantes relatives à l'utilisation des secrets.
Questions
Sécurité des secrets dans KMS
Lorsque vous créez un secret, vous devez spécifier une clé symétrique au sein de la même instance pour le chiffrer. KMS utilise cette clé pour chiffrer sous enveloppe la valeur du secret et stocke le résultat chiffré dans votre espace de stockage dédié.
KMS ne chiffre pas les métadonnées telles que le nom du secret, le numéro de version ou les libellés d'étape de version.
Après authentification et autorisation, KMS déchiffre le secret et le transmet de manière sécurisée à votre application via TLS 1.2.
Chiffrement des secrets
KMS chiffre les valeurs des secrets par chiffrement sous enveloppe. La clé de chiffrement est celle que vous spécifiez lors de la création du secret. Pour plus d'informations sur le chiffrement sous enveloppe, consultez la rubrique Utiliser des clés KMS pour le chiffrement sous enveloppe.
Message « Your secret is being rotated, please try again later »
|
Type |
Cause possible |
|
Secret RAM |
Le secret RAM est en cours de rotation. La rotation d'un secret RAM prend un certain temps, appelé fenêtre de rotation. Pour une rotation automatique périodique, la fenêtre de rotation est d'environ 48 heures. Pour une rotation immédiate, la fenêtre correspond à la durée que vous avez définie. Si la rotation n'est pas terminée dans le délai de la fenêtre de rotation, vérifiez dans Resource Access Management (RAM) si l'utilisateur RAM existe toujours. |
|
Secret ApsaraDB for RDS |
En règle générale, la rotation d'un secret ApsaraDB for RDS est immédiate. Si la rotation prend plus de 2 minutes, vérifiez l'état de l'instance ApsaraDB for RDS et du compte associé. |
|
Secret ECS |
Normalement, la rotation d'un secret ECS est immédiate. Si la rotation prend plus de 2 minutes, vérifiez l'état de l'instance ECS et du compte associé. |
Statut indisponible ou erreur « Rejected.Unavailable »
L'instance KMS qui contient le secret a expiré.
Vous devez renouveler l'instance KMS dans les 15 jours suivant son expiration. À défaut, l'instance sera libérée. Pour plus d'informations, consultez la rubrique Politique de renouvellement.
Si vous ne prévoyez pas d'utiliser l'instance KMS pour le moment, mais que vous pourriez avoir besoin de ses clés ou secrets à l'avenir, nous vous recommandons de les sauvegarder. Pour plus d'informations, consultez la rubrique Gestion des sauvegardes.
Impossible de trouver un secret dans la nouvelle console
La nouvelle console affiche uniquement les secrets gérés dans des instances KMS.
Auparavant, les utilisateurs disposant d'anciennes versions de KMS pouvaient créer des secrets sans instance KMS. Ces secrets ne sont pas pris en charge et ne peuvent pas être affichés dans la nouvelle console. Pour afficher ces secrets, accédez à l'ancienne console.
Échec de la vérification du compte pour un secret RDS
Cela se produit généralement parce que le compte de base de données ou l'instance associé(e) au secret ApsaraDB for RDS a été supprimé(e). Vérifiez que le compte et l'instance existent toujours dans ApsaraDB for RDS.
Erreur « You are not authorized » lors de la création d'un secret RAM
Cette erreur survient car l'utilisateur ou le rôle RAM actuel ne dispose pas des autorisations requises pour gérer les ressources cloud. Envoyez le lien d'autorisation à un administrateur RAM, tel qu'un utilisateur RAM disposant d'autorisations de gestion des ressources ou le compte Alibaba Cloud, afin qu'il vous accorde les autorisations nécessaires. Une fois les autorisations accordées par l'administrateur, retournez sur la page de création du secret RAM et cliquez sur Refresh ou actualisez la page. Pour plus d'informations, consultez la rubrique Étape 1 : Accorder à KMS les autorisations de gestion de la paire de clés AccessKey d'un utilisateur RAM.
Autorisations requises pour récupérer la valeur d'un secret
Les secrets étant stockés chiffrés dans KMS, vous avez également besoin de l'autorisation d'utiliser la clé pour le déchiffrement (Decrypt). La stratégie suivante accorde les autorisations minimales requises pour récupérer la valeur d'un secret via un appel d'API, mais pas depuis la console. Voici un exemple de stratégie d'autorisation :
{
"Version": "1",
"Statement": [{
"Effect": "Allow",
"Action": [
"kms:GetSecretValue",
"kms:Decrypt"
],
"Resource": [
"acs:kms:${region}:${account}:secret/example-secret",
"acs:kms:${region}:${account}:key/keyId-example"
]
}]
}Pour consulter d'autres exemples de stratégies d'autorisation, reportez-vous à la rubrique Exemples de stratégies d'autorisation personnalisées. Pour savoir comment accorder des autorisations à un utilisateur ou un rôle RAM, consultez les rubriques Accorder des autorisations à un utilisateur RAM et Accorder des autorisations à un rôle RAM.