Сам Terraform не может напрямую контролировать то, что разрешает или не разрешает консоль AWS.
Я думаю, чтобы получить такой эффект, вам нужно использовать очень детализированные политики IAM, чтобы учетные данные, которые ваша команда использует для входа в консоль AWS, не имеют доступа для внесения изменений в объекты, управляемые Terraform. Затем вы будете использовать разные учетные данные для запуска Terraform, к которым у do есть необходимый доступ.
Координация политик с таким тонким уровнем детализации будет сложной задачей. Я думаю, что самым близким приближением к тому, что вы показали в своем примере, была бы политика IAM, содержащая операторы «Запретить», которую вы затем связали бы со всеми принципалами, связанными с пользователями, имеющими AWS доступ к консоли.
resource "aws_sns_topic" "my_topic" {
name = "my_topic_name"
}
resource "aws_iam_policy" "disable_sns_console" {
name = "SNS Topic Disable Console"
# ...
policy = jsonencode({
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Deny",
"Resource": aws_sns_topic.my_topic.arn,
},
]
})
}
Вам потребуется найти некоторый подходящий объект пользователя, роли или группы IAM, чтобы присоединить эту политику и убедиться, что все учетные данные, используемые для доступа к консоли, связаны с любым объектом, который присваивает эту политику.
Этот вид политики «разрешать по умолчанию, запрещать указывать c объекты» сложно, потому что она «не удастся открыть», если вы не настроите ее правильно. Однако, если ваша цель больше вдохновить на хорошее поведение, чем внедрить безошибочный уровень безопасности, возможно, этот компромисс будет разумным.