Gerenciando a autenticação para suas instâncias do Event Streams

Event Streams suporta dois mecanismos SASL (Simple Authentication and Security Layer) como os métodos de autenticação para instâncias do Event Streams por padrão: PLAIN e OAUTHBEARER.

O cliente Kafka configurado com SASL PLAIN usa uma chave de API do IAM como uma senha de texto simples no processo de autenticação, o Event Streams envia a chave de API para o IAM para verificação. Quando autenticado, esse cliente permanecerá conectado e não precisará de nova autenticação até que ele seja desconectado e deseje se reconectar novamente.

O cliente Kafka configurado com SASL OAUTHBEARER usa o token de acesso do IAM no processo de autenticação, Event Streams verifica o token por meio da chave pública do IAM. Como um token de acesso do IAM tem um prazo de expiração (geralmente em 1 hora), o cliente Kafka é necessário para gerar novamente um novo token e passar pelo processo de autenticação novamente quando o token anterior estiver se aproximando do prazo de expiração.. Essa abordagem fornece melhor segurança em comparação com o SASL PLAIN de duas maneiras:

  1. A chave API sempre permanece no lado do cliente para gerar o token de acesso e não é mais enviada para brokers do Kafka na rede, o que remove o risco de exposição da chave API.
  2. O processo de autenticação acontece regularmente quando o token de acesso está expirando e isso minimiza o risco de exposição do token.

Para uma autenticação mais segura, o SASL OAUTHBEARER é o único método de autenticação recomendado para clientes Kafka. Consulte Configurando o cliente da API Kafka como configurar o SASL OAUTHBEARER em clientes Kafka.

Os usuários corporativos têm a opção de desativar SASL PLAIN em suas instâncias Enterprise. Use o comando a seguir:

ibmcloud resource service-instance-update <instance-name> -p '{"iam_token_only":true}'

Conectando ao Event Streams

Para obter mais informações sobre como obter uma credencial de chave de segurança para um aplicativo externo, consulte Conectando ao Event Streams.

Gerenciando a autorização para seus recursos do Event Streams

É possível assegurar os recursos do seu Event Streams de uma maneira com baixa granularidade para gerenciar o acesso que você deseja conceder a cada usuário para cada recurso.

Quando você altera as políticas e permissões do IAM, às vezes pode levar vários minutos para que elas sejam refletidas no serviço subjacente.

O que posso assegurar?

Dentro do Event Streams, você tem acesso seguro aos recursos a seguir:

  • Cluster (cluster): é possível controlar quais aplicativos e usuários podem se conectar ao serviço.
  • Tópicos (tópico): é possível controlar a capacidade dos usuários e aplicativos para criar, excluir, ler e escrever em um tópico.
  • Grupos de consumidores (grupo): é possível controlar a capacidade de um aplicativo de associar um grupo de consumidores.
  • Transações do produtor (txnid): é possível controlar a capacidade de usar o recurso de produtor transacional no Kafka (ou seja, gravações únicas atômicas em várias partições).

Os níveis de acesso (também conhecidos como função) que você pode atribuir a um usuário para cada recurso são os seguintes.

Exemplo de funções e ações do usuário Event Streams
Função de acesso Descrição das ações Ações de exemplo
Leitor Executar ações somente leitura no Event Streams, como visualizar recursos. Permitir que um app se conecte a um cluster designando acesso de leitura ao tipo de recurso de cluster.
Gravador Os gravadores têm permissões além da função de leitor, incluindo a edição de recursos do Event Streams. Permitir que um app produza para tópicos designando acesso de gravação a tipos de recurso de tópico e de nome de tópico.
Gerente Os gerentes têm permissões além da função de gravador para concluir ações privilegiadas. Além disso, é possível criar e editar recursos do Event Streams. Permitir o acesso total a todos os recursos, designando o acesso de gerenciamento à instância do Event Streams.

Como designar acesso?

Políticas do Cloud Identity and Access Management (IAM) são anexadas aos recursos para serem controladas. Cada política define o nível de acesso que um determinado usuário deve ter e a qual recurso ou conjunto de recursos. Uma política consiste nas informações a seguir:

  • O tipo de serviço ao qual a política se aplica. Por exemplo, Event Streams. É possível definir o escopo de uma política para incluir todos os tipos de serviço.
  • A instância do serviço a ser assegurada. É possível definir o escopo de uma política para incluir todas as instâncias de um tipo de serviço.
  • O tipo de recurso a ser assegurado. Os valores válidos são cluster, topic, group, schema ou txnid. Especificar um tipo é opcional. Se você não especificar um tipo, a política será então aplicada a todos os recursos na instância de serviço. Para especificar mais de um tipo de recurso, deve-se criar uma política por recurso.
  • O recurso a ser assegurado. Especifique para os recursos do tipo topic, group, schema e txnid. Se você não especificar o recurso, a política será então aplicada a todos os recursos do tipo especificado na instância de serviço.
  • A função atribuída ao usuário. Por exemplo, Leitor, Gravador ou Gerenciador.

Para obter mais informações sobre o IAM, consulte IBM Cloud Identity and gerenciamento de acesso.

Para obter um exemplo de como definir políticas, consulte IBM Cloud IAM Service IDs and API Keys.

Curinga

É possível aproveitar o recurso de curinga do IAM para configurar políticas para grupos de recursos no Event Streams. Por exemplo, se você der a todos os seus tópicos nomes como Dept1_Topic1 e Dept1_Topic2, poderá definir políticas para tópicos chamados Dept1_* e essas políticas serão aplicadas a todos os tópicos com esse prefixo. Para obter mais informações, consulte Atribuição de acesso usando políticas curinga.

Quais são as configurações de segurança padrão?

Por padrão, quando o Event Streams é provisionado, concede-se ao usuário que o provisionou a função de gerenciador para todos os recursos da instância. Além disso, qualquer usuário que tenha uma função de gerente para "Todos" os serviços ou "Todas" as instâncias de serviço Event Streams na mesma conta também tem acesso total.

Em seguida, é possível aplicar mais políticas para estender o acesso a outros usuários. É possível definir o escopo de uma política para aplicar ao Event Streams como um todo ou a recursos individuais no Event Streams. Para obter mais informações, consulte Ações comuns.

Somente usuários com função de administração de uma conta podem atribuir políticas a usuários. Designe políticas usando o painel do IBM Cloud ou usando os comandos ibmcloud.

Ações comuns

As tabelas a seguir resumem algumas ações comuns do Event Streams e o acesso que você precisa designar.

Requisitos do Cluster

Ao controlar o acesso ao recurso de cluster, é possível determinar quais aplicativos e usuários podem se conectar ao serviço Além das políticas necessárias para os tipos de recursos abaixo, o acesso ao ResourceType: Cluster e a um Role: Reader, Writer, Manager é necessário

Ações do produtor

A tabela a seguir descreve os requisitos de função e de recurso necessários para um usuário ou um aplicativo que produz mensagens para o Event Streams. Além das políticas necessárias para esse tipo de recurso, o acesso ao ResourceType: Cluster e a um Role: Reader, Writer, Manager é necessário

Ações do produtor
Ações do produtor Tópico Grupo txnid
Enviar uma mensagem para um tópico. Gravador Gravador [1]
Permitir que um aplicativo produza para um tópico de forma transacional. Gravador Leitor Gravador
Inicializar uma transação Gravador
Confirme uma transação Gravador Gravador
Abortar uma transação Gravador
Enviar deslocamentos para uma transação Leitor Gravador

Ações do consumidor

A tabela a seguir descreve os requisitos de função e de recurso necessários para um usuário ou aplicativo que consome mensagens do Event Streams. Além das políticas necessárias para esse tipo de recurso, o acesso ao ResourceType: Cluster e a um Role: Reader, Writer, Manager é necessário

Ações do consumidor
Ações do consumidor Tópico Grupo txnid
Permitir que um aplicativo consuma um tópico (grupo de consumidores). Leitor Leitor [2]
Permitir que um aplicativo se conecte e consuma a partir de um tópico específico (sem grupo de consumidores). Leitor
Permitir que um aplicativo se conecte e consuma a partir de qualquer tópico (sem grupo de consumidores). Leitor
Use o fluxo do Kafka Gerente Leitor
Excluir grupo de consumidores. Gerente
Designar. Leitor
Confirmar assíncrono Leitor Leitor
Sincronização de confirmação Leitor Leitor
Reforce o rebalanceamento Leitor
Pesquisa. Leitor
Assine. Leitor
Cancelar assinatura. Leitor Gravador

Ações de administração:

Além das políticas necessárias para esse tipo de recurso, o acesso ao ResourceType: Cluster e a um Role: Reader, Writer, Manager é necessário

Ações administrativas
Ações de administração: Tópico Grupo txnid
Altere as configurações do tópico Gerente
Altere os deslocamentos do grupo de consumidores Leitor Leitor
Criar partições.. Gerente
Criar tópicos.. Gerente
Excluir deslocamentos do grupo de consumidores. Leitor Gerente
Excluir grupos de consumidores. Gerente
Excluir registros. Gerente
Excluir tópicos. Gerente
Descreva os produtores Leitor
Produtores de cerca. Gravador
Altere incrementalmente as configurações de tópico Gerente
Remova os membros do grupo de consumidores Leitor

Ações do Registro de Esquema.

Com as ações do Schema Registry, é possível alterar a versão do esquema, como criar, atualizar e excluir versões de artefato ou artefato (somente plano Enterprise). Artefato é o termo que o Event Streams usa para descrever esquemas relacionados, geralmente associados e usados por um determinado tópico do Kafka O termo assunto geralmente é usado para descrever o mesmo conceito Para obter mais informações, consulte Usando Event Streams Schema Registry. Além das políticas necessárias para esse tipo de recurso, o acesso ao ResourceType: Cluster e a um Role: Reader, Writer, Manager é necessário

Ações do Schema Registry
Ações do Registro de Esquema. Esquema
Obtenha o artefato mais recente Leitor
Listar as versões Leitor
Obter versão. Leitor
Obter metadados por conteúdo. Leitor
Obter metadados. Leitor
Obter metadados da versão. Leitor
Obter a sequência de esquema identificada pelo ID de entrada. Leitor
Recuperar apenas o esquema identificado pelo ID de entrada. Leitor
Obtenha os pares de versão de assunto identificados pelo ID de entrada.. Leitor
Obter uma lista de versões registradas no assunto especificado. Leitor
Obter regra de compatibilidade de artefato. Leitor
Obtenha uma versão específica do esquema registrado sob este assunto. Leitor
Obtenha o esquema para a versão especificada deste assunto Leitor
Registrar um novo esquema no assunto especificado (se a versão já existir). Leitor
Verifique se um esquema já foi registrado sob o assunto especificado Leitor
Obter uma lista de IDs de esquemas que fazem referência ao esquema com o sujeito e a versão fornecidos. Leitor
Teste o esquema de entrada com relação a uma versão específica do esquema de um assunto para compatibilidade Leitor
Execute uma verificação de compatibilidade no esquema com relação a uma ou mais versões no assunto Leitor
Obter nível de compatibilidade para um sujeito. Leitor
Registrar um novo esquema sob o assunto especificado (se a versão deve ser criada). Gravador
Crie o artefato Gravador
Atualizar artefato. Gravador
Desativar artefato. Gravador
Crie a versão Gravador
Excluir versão. Gerente
Atualizar estado do artefato. Gerente
Atualizar estado da versão. Gerente
Excluir artefato. Gerente
Crie a regra de compatibilidade de artefato Gerente
Atualizar regra de compatibilidade de artefato. Gerente
Atualizar nível de compatibilidade para o assunto especificado. Gerente
Excluir regra de compatibilidade de artefato. Gerente
Exclui o assunto especificado e seu nível de compatibilidade associado, se registrado Gerente
Exclua uma versão específica do esquema registrado sob este assunto Gerente
Exclua a configuração do nível de compatibilidade de nível de assunto especificado e reverta para o padrão global Gerente
Atualize a regra de compatibilidade global [3]
Atualize o nível de compatibilidade global [4]

Ações de compatibilidade do Schema Registry

Para interoperação com aplicativos existentes, o Registro de Esquema do Event Streams suporta um subconjunto da API do Registro de Esquema do Confluent v7.2. Para executar essas ações, você precisa do acesso de nível de recurso a seguir:

Tabela de ações de compatibilidade
Ações de compatibilidade do Schema Registry Esquema
Obter a sequência de esquema identificada pelo ID de entrada. Leitor
Recupera apenas o esquema identificado pelo ID de entrada Leitor
Obtenha os tipos de esquema que são registrados com o Registro de Esquema
Obtenha os pares de versão de assunto identificados pelo ID de entrada.. Leitor
Obtenha uma lista de assuntos registrados
Obter uma lista de versões registradas no assunto especificado. Leitor
Exclui o assunto especificado e seu nível de compatibilidade associado, se registrado Gerente
Obtenha uma versão específica do esquema registrado sob este assunto. Leitor
Obtenha o esquema para a versão especificada deste assunto Leitor
Registre um novo esquema sob o assunto especificado leitor/gravador [5]
Verifique se um esquema já foi registrado sob o assunto especificado Leitor
Exclui uma versão específica do esquema registrado sob este assunto Gerente
Obter uma lista de IDs de esquemas que fazem referência ao esquema com o sujeito e a versão fornecidos. Leitor
Teste o esquema de entrada com relação a uma versão específica do esquema de um assunto para compatibilidade Leitor
Execute uma verificação de compatibilidade no esquema com relação a uma ou mais versões no assunto Leitor
Atualizar nível de compatibilidade global. [6]
Obter nível de compatibilidade global.
Atualizar nível de compatibilidade para o assunto especificado. Gerente
Obter nível de compatibilidade para um sujeito. Leitor
Exclui a configuração do nível de compatibilidade de nível de assunto especificado e reverte para o padrão global Gerente

Gerenciando o acesso ao Registro de esquema

O modelo de autorização do Schema Registry usa o mesmo estilo de políticas descrito na seção Gerenciando autorização para os seus recursos Event Streams deste documento.

Recursos do IAM

Com o novo tipo de recurso schema IAM, é possível criar políticas que controlam o acesso usando vários graus de granularidade, como nos exemplos a seguir.

  • Um esquema específico.
  • Um conjunto de esquemas selecionados por uma expressão curinga.
  • Todos os esquemas armazenados por uma instância do IBM Event Streams.
  • Todos os esquemas armazenados por todas as instâncias do IBM Event Streams em uma conta.

O Event Streams já tem o conceito de um tipo de recurso de cluster. É usado para controlar todo o acesso à instância de serviço, com a função mínima de Leitor sendo necessária para acessar qualquer ponto de extremidade Kafka ou HTTPS. Esse uso do tipo de recurso de cluster também é aplicado ao Schema Registry, no qual é necessária uma função mínima de Reader para acessar o registro.

Exemplo de cenários de autorização

A tabela a seguir descreve alguns exemplos de cenários para interagir com o Event Streams Juntamente com as funções exigidas pelos atores envolvidos. O processo de gerenciamento de esquemas é tratado separadamente para a implementação de aplicativos. Portanto, as políticas são necessárias tanto para a ID de serviço que gerencia os esquemas no registro quanto para o aplicativo que se conecta ao registro.

Exemplos de cenários de autorização
Cenário Pessoa ou função do processo Pessoa ou recurso do processo Função do Aplicativo Recurso de aplicativo
Novas versões de esquema são colocadas no registro por uma pessoa ou processo que é separado dos aplicativos que usam os esquemas. Reader
Writer
cluster
schema
Reader
Reader
cluster
schema
A adição de um esquema ao registro precisa especificar uma regra não padrão que controle como as versões do esquema podem evoluir. Reader
Manager
cluster
schema
Não aplicável Não aplicável
Os esquemas são gerenciados ao lado do código do aplicativo que usa o esquema. Novas versões de esquema são criadas no momento em que um aplicativo tenta usar a nova versão de esquema. Não aplicável Não aplicável Reader
Writer
cluster
schema
A regra padrão global que controla a evolução do esquema é mudada. Manager cluster Não aplicável Não aplicável

  1. O transcritor no txnid é necessário apenas para produção transacional ↩︎

  2. O leitor no grupo só será necessário se a designação fizer com que o consumidor saia de seu grupo atual ↩︎

  3. Você não precisa de acesso ao recurso de esquema, em vez disso, o acesso de Gerenciador no recurso de cluster é necessário ↩︎

  4. Você não precisa de acesso ao recurso de esquema, em vez disso, o acesso de Gerenciador no recurso de cluster é necessário ↩︎

  5. Leitor se a versão já existir, Gravador se a versão deve ser criada pela chamada API. ↩︎

  6. Você não precisa de acesso ao recurso de esquema, em vez disso, o acesso de Gerenciador no recurso de cluster é necessário ↩︎