Usar o controlo de acesso da IU do Airflow

Cloud Composer 3 | Cloud Composer 2 | Cloud Composer 1

Esta página descreve diferentes mecanismos de controlo de acesso para a IU do Airflow e a IU do DAG. Pode usar estes mecanismos, além do controlo de acesso fornecido pelo IAM, para separar os utilizadores na IU do Airflow e na IU do DAG do seu ambiente.

Vista geral do controlo de acesso à IU do Airflow no Cloud Composer

O acesso à IU do Airflow e à IU do DAG, bem como a visibilidade dos dados e das operações nessas IUs, são controlados a dois níveis no Cloud Composer:

  1. O acesso à IU do Airflow e à IU do DAG no Cloud Composer é controlado pela IAM.

    Se uma conta não tiver uma função que possa ver os ambientes do Cloud Composer no seu projeto, a IU do Airflow e a IU do DAG não estão disponíveis.

    O IAM não oferece qualquer controlo de autorizações detalhado adicional na IU do Airflow nem na IU do DAG.

  2. O modelo de controlo de acesso do Apache Airflow permite reduzir a visibilidade na IU do Airflow e na IU do DAG com base na função do utilizador.

    O controlo de acesso do Apache Airflow é uma funcionalidade do Airflow, com o seu próprio modelo de utilizadores, funções e autorizações, que é diferente do IAM.

O controlo de acesso do Apache Airflow usa autorizações baseadas em recursos. Todos os utilizadores do Airflow com uma função específica do Airflow recebem as autorizações desta função. Por exemplo, os utilizadores do Airflow que tenham uma função com a autorização can delete on Connections podem eliminar associações na página Associações na IU do Airflow.

Também pode atribuir autorizações ao nível do DAG para DAGs individuais. Por exemplo, para que apenas os utilizadores com uma função específica do Airflow possam ver um determinado DAG na IU do Airflow. No Cloud Composer, pode atribuir automaticamente autorizações ao nível do DAG com base na subpasta onde o ficheiro DAG está localizado no contentor do ambiente.

Se quiser configurar o acesso para identidades externas através da federação de identidades da força de trabalho, primeiro conceda acesso ao seu ambiente no IAM, conforme descrito na secção Conceda funções do IAM a identidades externas. Posteriormente, pode usar o controlo de acesso da IU do Airflow como habitualmente. Os utilizadores do Airflow para identidades externas usam o respetivo identificador principal em vez do endereço de email e têm valores diferentes preenchidos noutros campos de registo de utilizadores do que as Contas Google.

Antes de começar

Faça a gestão das funções do Airflow e das definições de controlo de acesso

Os utilizadores com a função de administrador (ou equivalente) podem ver e modificar as definições de controlo de acesso na IU do Airflow.

Na IU do Airflow, pode configurar as definições de controlo de acesso no menu Segurança. Para mais informações sobre o modelo de controlo de acesso do Airflow, as autorizações disponíveis e as funções predefinidas, consulte a documentação de controlo de acesso da IU do Airflow.

O Airflow mantém a sua própria lista de utilizadores. Os utilizadores com a função de administrador (ou equivalente) podem ver a lista de utilizadores que abriram a IU do Airflow de um ambiente e que foram registados no Airflow. Esta lista também inclui utilizadores pré-registados manualmente por um administrador, conforme descrito na secção seguinte.

Registe utilizadores na IU do Airflow

Os novos utilizadores são registados automaticamente quando abrem a IU do Airflow de um ambiente do Cloud Composer pela primeira vez.

No registo, os utilizadores recebem a função especificada na [webserver]rbac_user_registration_role opção de configuração do Airflow. Pode substituir esta opção de configuração do Airflow por um valor diferente para controlar a função dos utilizadores recém-registados.

Se não for especificado, a função de registo predefinida é Op em ambientes com o Airflow 2.

Recomendamos os seguintes passos para criar uma configuração de função básica para a IU do Airflow:

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

  2. Conceda a função de Admin às contas de administrador. A função predefinida para novas contas em ambientes com o Airflow 2 é Op. Para atribuir a função Admin, execute o seguinte comando da CLI do Airflow com a CLI gcloud:

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

    Substituir:

    • ENVIRONMENT_NAME com o nome do ambiente.
    • LOCATION com a região onde o ambiente está localizado.
    • USER_EMAIL com o email de uma conta de utilizador.

  3. Os administradores podem agora configurar o controlo de acesso para novos utilizadores, incluindo a concessão da função Admin a outros utilizadores.

Pré-registe utilizadores

Os utilizadores são registados automaticamente com IDs numéricos de contas de utilizador Google (não endereços de email) como nomes de utilizador. Também pode pré-registar manualmente um utilizador e atribuir-lhe uma função adicionando um registo de utilizador com o campo do nome de utilizador definido para o endereço de email principal do utilizador. Quando um utilizador com um endereço de email correspondente a um registo de utilizador pré-registado inicia sessão na IU do Airflow pela primeira vez, o respetivo nome de utilizador é substituído pelo ID do utilizador atualmente (no momento do primeiro início de sessão) identificado pelo respetivo endereço de email. A relação entre as identidades Google (endereços de email) e as contas de utilizador (IDs de utilizador) não é fixa. Não é possível pré-registar grupos Google.

Para fazer o pré-registo de utilizadores, pode usar a IU do Airflow ou executar um comando da CLI do Airflow através da CLI do Google Cloud.

Para pré-registar um utilizador com uma função personalizada através da 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 o seguinte:

  • ENVIRONMENT_NAME: o nome do ambiente
  • LOCATION: a região onde o ambiente está localizado
  • ROLE: uma função do Airflow para o utilizador, por exemplo, Op
  • USER_EMAIL: o endereço de email do utilizador
  • FIRST_NAME e LAST_NAME: nome próprio e apelido do utilizador

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 utilizadores

A eliminação de um utilizador do Airflow não revoga o acesso desse utilizador, porque este é registado automaticamente novamente na próxima vez que aceder à IU do Airflow. Para revogar o acesso a toda a IU do Airflow, remova a autorização da respetiva política de autorização para o seu projeto.composer.environments.get

Também pode alterar a função do utilizador para Público, o que mantém o registo do utilizador, mas remove todas as autorizações para a IU do Airflow.

Configure automaticamente as autorizações ao nível do DAG

A funcionalidade de registo de funções por pasta cria automaticamente uma função do Airflow personalizada para cada subpasta diretamente na pasta /dags e concede a esta função acesso ao nível do DAG a todos os DAGs cujo ficheiro de origem esteja armazenado nessa respetiva subpasta. Isto simplifica a gestão das funções personalizadas do Airflow e o respetivo acesso aos DAGs.

Como funciona o registo de funções por pasta

O registo de funções por pasta é uma forma automática de configurar funções e as respetivas autorizações ao nível do DAG. Como tal, pode causar conflitos com outros mecanismos do Airflow que concedem autorizações ao nível do DAG:

Para evitar tais conflitos, a ativação do registo de funções por pasta também altera o comportamento destes mecanismos.

No Airflow 2:

  • Pode conceder acesso a funções do DAG através da propriedade access_control definida no código fonte do DAG.
  • A concessão manual de autorizações de DAG (através da IU do Airflow ou da CLI gcloud) pode causar conflitos. Por exemplo, se conceder manualmente autorizações ao nível do DAG a uma função por pasta, estas autorizações podem ser removidas ou substituídas quando o processador de DAG sincroniza um DAG. Recomendamos que não conceda autorizações de DAG manualmente.
  • As funções têm uma união de autorizações de acesso DAG registadas através do registo de funções 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 nenhuma função por pasta. Não são acessíveis com nenhuma função por pasta. Outras funções, como administrador, operador, utilizador ou qualquer função personalizada à qual sejam concedidas autorizações, podem aceder a estes recursos através da IU do Airflow e da IU DAG.

Se carregar DAGs para subpastas com nomes que correspondam às funções incorporadas do Airflow e às funções criadas pelo Cloud Composer, as autorizações para DAGs nestas subpastas continuam a ser atribuídas a estas funções. Por exemplo, carregar um DAG para a pasta /dags/Admin concede autorizações a este DAG para a função de administrador. As funções integradas do Airflow incluem administrador, operador, utilizador, leitor e público. O Cloud Composer cria NoDags e UserNoDags depois de a funcionalidade de registo de funções por pasta ser ativada.

O Airflow executa o registo de funções por pasta quando processa DAGs no agendador do Airflow. Se existirem mais de cem DAGs no seu ambiente, pode observar um aumento no tempo de análise dos DAGs. Se for o caso, recomendamos que use mais memória e CPU para os programadores. Também pode aumentar o valor da opção de configuração do [scheduler]parsing_processes Airflow.

Atribua automaticamente DAGs a funções por pasta

Para atribuir automaticamente DAGs a funções por pasta:

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

    Secção Chave Valor
    webserver rbac_autoregister_per_folder_roles True

  2. Altere a função de registo de novos utilizadores para uma função sem acesso a nenhum DAG. Desta forma, os novos utilizadores não têm acesso a nenhum DAG até que um administrador atribua uma função com autorizações para DAGs específicos às respetivas contas.

    UserNoDags é uma função criada pelo Cloud Composer apenas quando a funcionalidade de registo de funções por pasta está ativada. É equivalente à função de utilizador, mas sem acesso a nenhum DAG.

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

    Secção Chave Valor
    webserver rbac_user_registration_role UserNoDags

  3. Certifique-se de que os utilizadores estão registados no Airflow.

  4. Atribua funções aos utilizadores através de uma das seguintes abordagens:

    • Permita que o Airflow crie automaticamente funções com base nas subpastas dos DAGs e, em seguida, atribua utilizadores a estas funções.
    • Pré-crie funções vazias para as subpastas dos DAGs, com nomes de funções correspondentes ao nome de uma subpasta e, em seguida, atribua utilizadores a estas funções. Por exemplo, para a pasta /dags/CustomFolder, crie uma função denominada CustomFolder.

  5. Carregue DAGs para subpastas com nomes que correspondam às funções atribuídas aos utilizadores. Estas subpastas têm de estar localizadas na pasta /dags no contentor do ambiente. O Airflow adiciona autorizações aos DAGs numa subpasta, para que apenas os utilizadores com a função correspondente possam aceder aos mesmos através da IU do Airflow e da IU do DAG.

Configure manualmente as autorizações ao nível do DAG

Pode configurar autorizações ao nível do DAG para funções personalizadas de modo a especificar que DAGs são visíveis para grupos de utilizadores específicos.

Para configurar autorizações ao nível do DAG na IU do Airflow:

  1. O administrador cria funções vazias para agrupar DAGs.
  2. O administrador atribui os utilizadores às funções adequadas.
  3. O administrador ou os utilizadores atribuem DAGs a funções.
  4. Na IU do Airflow, os utilizadores só podem ver os DAGs atribuídos ao respetivo grupo.

Os DAGs podem ser atribuídos a funções através das propriedades dos DAGs ou da IU do Airflow.

Atribuir DAGs a funções na IU do Airflow

Um administrador pode atribuir as autorizações necessárias ao nível do DAG às funções adequadas na IU do Airflow.

Esta operação não é suportada na IU do DAG.

Atribuir DAGs a funções nas propriedades de DAGs

Pode definir o access_control parâmetro DAG num DAG, especificando as funções de agrupamento de DAG às quais o DAG está atribuído.

Nas versões do Airflow anteriores à 2.1.0, o administrador, o programador de DAG ou um processo automatizado tem de executar o sync-perm comando do Airflow para aplicar as novas definições de controlo de acesso.

No Airflow 2.1.0 e versões posteriores, a execução deste comando já não é necessária, porque o agendador aplica autorizações ao nível do DAG quando analisa um DAG.

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

Mapeie os registos de auditoria na IU do Airflow para os utilizadores

Os registos de auditoria na IU do Airflow são mapeados para IDs numéricos de contas de utilizadores Google. Por exemplo, se um utilizador pausar um DAG, é adicionada uma entrada aos registos.

Pode ver os registos de auditoria na página Procurar > Registos de auditoria na IU do Airflow.

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

Uma entrada típica apresenta um ID numérico no campo Proprietário: accounts.google.com:NUMERIC_ID. Pode mapear IDs numéricos para emails de utilizadores na página Segurança > Listar utilizadores. Esta página está disponível para utilizadores com a função Admin.

Tenha em atenção que a relação entre as identidades Google (endereços de email) e as contas de utilizador (IDs de utilizador) não é fixa.

O que se segue?