Creación de políticas de autorización para el rol de IAM - Transmisión administrada de Amazon para Apache Kafka

Creación de políticas de autorización para el rol de IAM

Asocie una política de autorización al rol de IAM que corresponda al cliente. En una política de autorización, se especifican las acciones que se van a permitir o denegar para el rol. Si su cliente está en una instancia de Amazon EC2, asocie la política de autorización al rol de IAM de esa instancia de Amazon EC2. Como alternativa, puede configurar su cliente para que utilice un perfil con nombre y, a continuación, asociar la política de autorización al rol de ese perfil con nombre. Configuración de clientes para el control de acceso de IAM describe cómo configurar un cliente para utilizar un perfil con nombre asignado.

Para obtener más información sobre cómo crear una política de IAM, consulte Creación de políticas de IAM.

A continuación, se muestra un ejemplo de política de autorización para un clúster denominado MyTestCluster. Para entender la semántica de los elementos Action y Resource, consulte Semántica de las acciones y los recursos de la política de autorización de IAM.

importante

Los cambios que realice en una política de IAM se reflejan en las API de IAM y en la AWS CLI de manera inmediata. Sin embargo, puede pasar un tiempo considerable hasta que el cambio en la política surta efecto. En la mayoría de los casos, los cambios en la política entran en vigor en menos de un minuto. En ocasiones, las condiciones de la red pueden aumentar la demora.

JSON
{
    "Version":"2012-10-17",		 	 	 
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "kafka-cluster:Connect",
                "kafka-cluster:AlterCluster",
                "kafka-cluster:DescribeCluster"
            ],
            "Resource": [
                "arn:aws:kafka:us-east-1:111122223333:cluster/MyTestCluster/abcd1234-0123-abcd-5678-1234abcd-1"
            ]
        },
        {
            "Effect": "Allow",
            "Action": [
                "kafka-cluster:*Topic*",
                "kafka-cluster:WriteData",
                "kafka-cluster:ReadData"
            ],
            "Resource": [
                "arn:aws:kafka:us-east-1:123456789012:topic/MyTestCluster/*"
            ]
        },
        {
            "Effect": "Allow",
            "Action": [
                "kafka-cluster:AlterGroup",
                "kafka-cluster:DescribeGroup"
            ],
            "Resource": [
                "arn:aws:kafka:us-east-1:123456789012:group/MyTestCluster/*"
            ]
        }
    ]
}

Para obtener información sobre cómo crear una política con elementos de acción que se correspondan con los casos de uso habituales de Apache Kafka, como la producción y el consumo de datos, consulte Casos de uso habituales de la política de autorización de clientes.

En las versiones 2.8.0 y posteriores de Kafka, el permiso WriteDataIdempotently está obsoleto (KIP-679). Se utiliza enable.idempotence = true de forma predeterminada. Por lo tanto, para las versiones de Kafka 2.8.0 y posteriores, IAM no ofrece la misma funcionalidad que las ACL de Kafka. No es posible WriteDataIdempotently en un tema si se proporciona únicamente acceso de WriteData a ese tema. Esto no afecta al caso en el que se proporciona WriteData a TODOS los temas. En ese caso, WriteDataIdempotently está permitido. Esto se debe a las diferencias en la implementación de la lógica de IAM y a la forma en que se implementan las ACL de Kafka. Además, la escritura idempotente en un tema también requiere acceso a transactional-ids.

Para solucionar esta limitación, se recomienda utilizar una política similar a la que se muestra a continuación.

JSON
{
    "Version":"2012-10-17",		 	 	 
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "kafka-cluster:Connect",
                "kafka-cluster:AlterCluster",
                "kafka-cluster:DescribeCluster",
                "kafka-cluster:WriteDataIdempotently"
            ],
            "Resource": [
                "arn:aws:kafka:us-east-1:123456789012:cluster/MyTestCluster/abcd1234-0123-abcd-5678-1234abcd-1"
            ]
        },
        {
            "Effect": "Allow",
            "Action": [
                "kafka-cluster:*Topic*",
                "kafka-cluster:WriteData",
                "kafka-cluster:ReadData"
            ],
            "Resource": [
                "arn:aws:kafka:us-east-1:123456789012:topic/MyTestCluster/abcd1234-0123-abcd-5678-1234abcd-1/TestTopic",
                "arn:aws:kafka:us-east-1:123456789012:transactional-id/MyTestCluster/abcd1234-0123-abcd-5678-1234abcd-1/*"
            ]
        }
    ]
}

En este caso, WriteData permite escribir en TestTopic y, al mismo tiempo, WriteDataIdempotently permite escrituras idempotentes en el clúster. Esta política también agrega acceso a los recursos de transactional-id que serán necesarios.

Dado que WriteDataIdempotently es un permiso a nivel de clúster, no se puede utilizar a nivel de tema. Si WriteDataIdempotently se restringe al nivel de tema, esta política no funcionará.