como usar o controle de acesso da interface do Airflow

Cloud Composer 1 | Cloud Composer 2

Nesta página, descrevemos vários mecanismos de controle de acesso à interface do Airflow e à interface do DAG. É possível usar esses mecanismos, além do controle de acesso fornecido pelo IAM, para separar usuários na interface do Airflow e do DAG do ambiente.

Visão geral do controle de acesso da interface do Airflow no Cloud Composer

O acesso à interface do Airflow e do DAG e à visibilidade dos dados e operações nessas interfaces é controlado em dois níveis no Cloud Composer:

  1. O acesso à interface do Airflow e do DAG no Cloud Composer é controlado pelo IAM.

    Se uma conta não tiver um papel que possa visualizar os ambientes do Cloud Composer no seu projeto, esses recursos não estarão disponíveis.

    O IAM não fornece nenhum controle de permissão mais refinado na IU do Airflow ou do DAG.

  2. O modelo de controle de acesso do Apache Airflow permite reduzir a visibilidade na interface do Airflow e na interface do DAG com base no função do usuário.

    O controle de acesso do Apache Airflow é um recurso do Airflow, com um modelo próprio de usuários, papéis e permissões, que é diferente do IAM.

O controle de acesso do Apache Airflow usa permissões baseadas em recursos. Todos os usuários do Airflow com um papel específico recebem as permissões desse papel. Por exemplo, os usuários do Airflow que têm um papel com a permissão can delete on Connections podem excluir conexões na página "Conexões" na IU do Airflow.

Também é possível atribuir permissões no nível do DAG para DAGs individuais. Por exemplo, para que apenas os usuários com um papel específico do Airflow possam ver um determinado DAG na IU do Airflow. No Cloud Composer, é possível atribuir permissões automaticamente no nível do DAG com base na subpasta em que o arquivo DAG está localizado no bucket do ambiente.

Antes de começar

  • A interface do Airflow com controle de acesso está disponível para as versões 1.13.4 ou posteriores do Cloud Composer e do Airflow 1.10.10 e posteriores. O ambiente também precisa executar o Python 3.

  • O registro de papéis por pasta está disponível no Cloud Composer 1.18.12 e versões posteriores no Airflow 2 e no Cloud Composer 1.13.4 e versões posteriores no Airflow 1.

ative a interface do Airflow com controle de acesso

Airflow 2

A interface do Airflow com controle de acesso está sempre ativada no Airflow 2.

Airflow 1

Para ativar a IU do Airflow com controle de acesso, substitua a seguinte opção de configuração do Airflow:

Seção Chave Valor
webserver rbac True

É possível fazer isso para um ambiente existente ou ao criar um novo.

Com essa configuração, seu ambiente executa a interface do Airflow com controle de acesso em vez da interface clássica do Airflow.

Gerenciar papéis do Airflow e configurações de controle de acesso

Os usuários com o papel de administrador (ou equivalente) podem ver e modificar as configurações de controle de acesso na interface do Airflow.

Na IU do Airflow, é possível definir as configurações de controle de acesso no menu Segurança. Para mais informações sobre o modelo de controle de acesso do Airflow, as permissões disponíveis e os papéis padrão, consulte a documentação do controle de acesso da interface do Airflow.

O Airflow 1 trata o papel de usuário como um modelo para todos os papéis personalizados. O Airflow copia continuamente as permissões do papel de usuário para todos os papéis personalizados, exceto as permissões all_dags.

O Airflow mantém a própria lista de usuários. Os usuários com o papel de administrador (ou equivalente) podem visualizar a lista de usuários que abriram a interface do Airflow de um ambiente e foram registrados no Airflow. Essa lista também inclui usuários pré-registrados manualmente por um administrador, conforme descrito na seção a seguir.

Registrar usuários na interface do Airflow

Os novos usuários são registrados automaticamente quando abrem a interface do Airflow de um ambiente do Cloud Composer pela primeira vez.

No registro, os usuários recebem o papel especificado na opção de configuração [webserver]rbac_user_registration_role do Airflow. É possível controlar o papel de usuários recém-registrados substituindo essa opção de configuração do Airflow por um valor diferente.

Se não for especificado, o papel de registro padrão será Op em ambientes com o Airflow 2.

Em ambientes com o Airflow 1.10.*, o papel de registro padrão é Admin.

Siga estas etapas para criar uma configuração de papel básico na IU do Airflow:

Airflow 2

  1. Os administradores do ambiente abrem a interface do Airflow para o ambiente recém-criado.

  2. Conceda às contas de administrador o papel Admin. O papel padrão para novas contas em ambientes com o Airflow 2 é:Op de dados. Para atribuir o papel Admin, execute o seguinte comando da CLI do Airflow com gcloud:

      gcloud composer environments run ENVIRONMENT_NAME \
    --location LOCATION \
    users add-role -- -e USER_EMAIL -r Admin

    Substitua:

    • ENVIRONMENT_NAME pelo nome do ambiente
    • LOCATION pela região em que o ambiente está localizado;
    • USER_EMAIL pelo e-mail de uma conta de usuário.

  3. Agora os administradores podem configurar o controle de acesso para novos usuários, incluindo a concessão do papel Admin para outros usuários.

Airflow 1

  1. Os administradores do ambiente abrem a IU do Airflow para o ambiente recém-criado, em que são registrados automaticamente com o papel Admin.

  2. Modifique a seguinte opção de configuração do Airflow para o papel necessário para novos usuários. Por exemplo, para User.

    Seção Chave Valor
    webserver rbac_user_registration_role User ou outro papel que não seja de administrador

  3. Agora, os administradores podem configurar o controle de acesso da IU do Airflow para novos usuários, incluindo a concessão do papel Admin a outros usuários.

Usuários do pré-registro

Os usuários são registrados automaticamente com IDs numéricos de contas de usuário do Google (não endereços de e-mail) como nomes de usuário. Também é possível fazer o pré-registro manual de um usuário e atribuir um papel a ele. Para isso, adicione um registro de usuário com o campo de nome de usuário definido como o endereço de e-mail principal do usuário. Quando um usuário com um endereço de e-mail correspondente a um registro de usuário pré-registrado faz login na interface do Airflow pela primeira vez, o nome de usuário é substituído pelo ID do usuário identificado no momento do primeiro login. A relação entre identidades do Google (endereços de e-mail) e contas de usuário (IDs de usuário) não é fixa. Os grupos do Google não podem ser pré-registrados.

Para fazer o pré-registro de usuários, use a interface do Airflow ou execute um comando da CLI do Airflow por meio da Google Cloud CLI.

Para fazer o pré-registro de um usuário com um papel personalizado na Google Cloud CLI, execute o seguinte comando da CLI do Airflow:

gcloud composer environments run ENVIRONMENT_NAME \
  --location LOCATION \
  users create -- \
  -r ROLE \
  -e USER_EMAIL \
  -u USER_EMAIL \
  -f FIRST_NAME \
  -l LAST_NAME \
  --use-random-password # The password value is required, but is not used

Substitua:

  • ENVIRONMENT_NAME: o nome do ambiente.
  • LOCATION: a região em que o ambiente está localizado.
  • ROLE: um papel do Airflow para o usuário, por exemplo, Op
  • USER_EMAIL: endereço de e-mail do usuário
  • FIRST_NAME e LAST_NAME: nome e sobrenome do usuário

Exemplo:

gcloud composer environments run example-environment \
  --location us-central1 \
  users create -- \
  -r Op \
  -e "example-user@example.com" \
  -u "example-user@example.com" \
  -f "Name" \
  -l "Surname" \
  --use-random-password

Remover usuários

Excluir um usuário do Airflow não revoga o acesso dele, porque ele será registrado automaticamente novamente na próxima vez que acessar a IU do Airflow. Para revogar o acesso a toda a IU do Airflow, remova a permissão composer.environments.get da política de permissão do projeto.

Também é possível alterar o papel do usuário para "Público", que mantém o registro do usuário, mas remove todas as permissões da interface do Airflow.

Configurar permissões no nível do DAG automaticamente

O recurso de registro de papéis por pasta cria automaticamente um papel personalizado do Airflow para cada subpasta diretamente dentro da pasta /dags e concede a esse papel acesso no nível do DAG a todos os DAGs que tenham o arquivo de origem armazenado na respectiva subpasta. Isso simplifica o gerenciamento dos papéis personalizados do Airflow e o acesso deles aos DAGs.

Como funciona o registro de funções por pasta

O registro de papéis por pasta é uma maneira automatizada de configurar papéis e as respectivas permissões no nível do DAG. Por isso, ele pode causar conflitos com outros mecanismos do Airflow que concedem permissões no nível do DAG:

Para evitar esses conflitos, ativar o registro de papéis por pasta também muda o comportamento desses mecanismos.

No Airflow 1, a possibilidade de usar esses mecanismos é desativada quando o registro de papéis por pasta está ativado. Todo o gerenciamento de permissões no nível do DAG acontece somente por meio do registro de papéis por pasta.

No Airflow 2:

  • É possível conceder acesso ao DAG aos papéis por meio da propriedade access_control definida no código-fonte do DAG.
  • A concessão manual de permissões do DAG, pela interface do Airflow ou pela CLI gcloud, pode causar conflitos. Por exemplo, se você conceder manualmente permissões no nível do DAG para um papel por pasta, essas permissões poderão ser removidas ou substituídas quando o processador de DAG sincronizar um DAG. Recomendamos não conceder permissões de DAG manualmente.
  • Os papéis unem as permissões de acesso do DAG registradas por meio do registro de papéis por pasta e definidas na propriedade access_control do DAG.

Os DAGs localizados diretamente na pasta /dags de nível superior não são atribuídos automaticamente a nenhum papel por pasta. Eles não podem ser acessados em papéis por pasta. Outros papéis, como Administrador, Operações, Usuário ou qualquer papel personalizado com permissões, podem acessá-los por meio da IU do Airflow e do DAG.

Se você fizer upload de DAGs para subpastas com nomes que correspondam aos papéis integrados do Airflow e papéis criados pelo Cloud Composer, as permissões para DAGs nessas subpastas ainda serão atribuídas a esses papéis. Por exemplo, fazer upload de um DAG para a pasta /dags/Admin concede permissões a esse DAG ao papel Administrador. Os papéis integrados do Airflow incluem Administrador, Operações, Usuário, Leitor e Público. O Cloud Composer cria NoDags e UserNoDags depois que o recurso de Registro de papéis por pasta é ativado.

O Airflow executa o registro de papéis por pasta quando processa DAGs no programador do Airflow. Se houver mais de cem DAGs no ambiente, talvez você note um aumento no tempo de análise de DAGs. Nesse caso, recomendamos aumentar o parâmetro [scheduler]max_threads para um ambiente do Airflow 1 ou [scheduler]parsing_processes para o Airflow 2.

Atribuir DAGs automaticamente a papéis por pasta

Para atribuir DAGs automaticamente a papéis por pasta:

  1. Substitua a seguinte opção de configuração do Airflow:

    Seção Chave Valor
    webserver rbac_autoregister_per_folder_roles True

  2. Altere o novo papel de registro de usuário para um papel sem acesso a nenhum DAG. Dessa forma, os novos usuários não terão acesso a nenhum DAG até que um administrador atribua um papel com permissões para DAGs específicos às contas deles.

    UserNoDags e NoDags são papéis criados pelo Cloud Composer somente quando o recurso de registro de papéis por pasta está ativado. Eles são equivalentes ao papel de usuário, mas sem acesso a nenhum DAG. O papel UserNoDags é criado no Airflow 2, e o papel NoDags no Airflow 1.

    No Airflow 2, substitua a seguinte opção de configuração do Airflow:

    Seção Chave Valor
    webserver rbac_user_registration_role UserNoDags

    No Airflow 1, substitua a seguinte opção de configuração do Airflow:

    Seção Chave Valor
    webserver rbac_user_registration_role NoDags

  3. Verifique se os usuários estão registrados no Airflow.

  4. Atribua papéis aos usuários com uma destas abordagens:

    • Permita que o Airflow crie papéis automaticamente com base nas subpastas de DAGs e atribua usuários a esses papéis.
    • Crie previamente papéis vazios para as subpastas de DAGs, com nomes de papéis correspondentes ao nome de uma subpasta. Em seguida, atribua usuários a esses papéis. Por exemplo, para a pasta /dags/CustomFolder, crie um papel chamado CustomFolder.

  5. Fazer upload de DAGs para subpastas com nomes que correspondam aos papéis atribuídos aos usuários. Essas subpastas precisam estar localizadas na pasta /dags no bucket do ambiente. O Airflow adiciona permissões aos DAGs nessa subpasta, para que apenas os usuários com o papel correspondente possam acessá-los por meio da IU do Airflow e do DAG.

Configurar permissões no nível do DAG manualmente

É possível configurar permissões no nível do DAG para papéis personalizados a fim de especificar quais DAGs são visíveis para grupos de usuários específicos.

Para configurar permissões no nível do DAG na IU do Airflow:

  1. O administrador cria papéis vazios para agrupar DAGs.
  2. O administrador atribui os usuários às funções apropriadas.
  3. O administrador ou os usuários atribuem DAGs a papéis.
  4. Na interface do Airflow, os usuários só podem ver os DAGs atribuídos ao grupo.

Os DAGs podem ser atribuídos a papéis por meio de propriedades do DAG ou da interface do usuário do Airflow.

como atribuir DAGs a papéis na IU do Airflow

Um administrador pode atribuir as permissões necessárias no nível do DAG aos papéis apropriados na IU do Airflow.

Esta operação não é compatível com a interface do DAG.

Como atribuir DAGs a papéis nas propriedades do DAG

É possível definir o parâmetro access_control do DAG em um DAG, especificando os papéis de agrupamento por DAG atribuído ao DAG.

Nas versões 2 do Airflow anteriores à 2.1.0, o administrador, o desenvolvedor de DAG ou um processo automatizado precisa executar o comando sync-perm do Airflow para aplicar as novas configurações de controle de acesso.

No Airflow 2.1.0 e versões posteriores, a execução desse comando não é mais necessária, porque o programador aplica permissões no nível do DAG ao analisar um DAG.

Airflow 2 

dag = DAG(
  access_control={
    'DagGroup': {'can_edit', 'can_read'},
  },
  ...
  )

Airflow 1 

dag = DAG(
  access_control={
    'DagGroup': {'can_dag_edit', 'can_dag_read'},
  },
  ...
  )

Mapear registros de auditoria na interface do Airflow para os usuários

Os registros de auditoria na interface do Airflow são mapeados para IDs numéricos de contas de usuário do Google. Por exemplo, se um usuário pausar um DAG, uma entrada será adicionada aos registros.

Airflow 2

No Airflow 2, é possível ver os registros de auditoria na página Procurar > Registros de auditoria na IU do Airflow.

Uma entrada na página "Registros de auditoria" no Airflow 2
Figura 1. Uma entrada na página "Registros de auditoria" no Airflow 2

Airflow 1

No Airflow 1, é possível ver os registros de auditoria na página Procurar > Registros.

Uma entrada na página Registros no Airflow 1
Figura 1. Uma entrada na página "Registros" no Airflow 1

Uma entrada típica lista um ID numérico no campo Owner: accounts.google.com:NUMERIC_ID. Você pode mapear IDs numéricos para e-mails de usuários na página Segurança > Listar usuários. Essa página está disponível para usuários com o papel Admin.

A relação entre identidades do Google (endereços de e-mail) e contas de usuário (IDs de usuário) não é fixa.

A seguir