Cloud Composer 1 | Cloud Composer 2 | Cloud Composer 3
Nesta página, descrevemos diferentes mecanismos de controle de acesso para a interface do Airflow e a interface de DAG. É possível usar esses mecanismos, além do controle de acesso fornecido pelo IAM, para separar usuários na interface do Airflow e da DAG do seu ambiente.
Visão geral do controle de acesso da interface do Airflow no Cloud Composer
Acesso à interface do Airflow e do DAG e à a visibilidade dos dados e das operações nessas interfaces é controlada em dois níveis O Cloud Composer:
O acesso às interfaces do Airflow e do DAG no Cloud Composer é controladas pelo IAM.
Se uma conta não tem um papel que pode conferir os ambientes do Cloud Composer na sua a interface do Airflow e do DAG não estarão disponíveis.
O IAM não fornece recursos de na interface do Airflow ou do DAG.
O modelo de controle de acesso do Apache Airflow permite reduzir a visibilidade na IU do Airflow e na IU da DAG com base na 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 uma função específica recebem as permissões desse papel. Por exemplo,
os usuários do Airflow que têm uma função com a permissão can delete on Connections
podem excluir conexões na página "Conexões" da interface do Airflow.
Também é possível atribuir permissões no nível do DAG para DAGs individuais. Por exemplo, para que apenas usuários com um papel específico do Airflow possam ver um determinado DAG na interface do Airflow. No Cloud Composer, é possível atribuir automaticamente permissões 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 Versões do Cloud Composer 1.13.4 ou mais recentes e Airflow 1.10.10 e versões mais recentes. 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 em versões mais recentes no Airflow 2 e no Cloud Composer 1.13.4 e em versões mais recentes no Airflow 1.
Ativar o controle de acesso da interface do Airflow
Airflow 2
A interface do Airflow com controle de acesso está sempre ativada no Airflow 2.
Airflow 1
Para ativar a interface do Airflow com o controle de acesso, substitua o 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 acesso Controle em vez da interface clássica do Airflow.
Gerenciar papéis e configurações de controle de acesso do Airflow
Usuários com a função de administrador (ou equivalente) podem conferir e modificar o controle de acesso na interface do Airflow.
Na interface do Airflow, é possível configurar as configurações de controle de acesso no menu Security. Para mais informações sobre o serviço permissões disponíveis e papéis padrão, consulte a Documentação do controle de acesso à IU do Airflow.
O Airflow 1 trata a função de usuário como um modelo para todas as funções personalizadas. O Airflow
copia continuamente as permissões da função "Usuário" para todas as funções personalizadas, exceto
as permissões da all_dags
.
O Airflow mantém a própria lista de usuários. Usuários com o papel "Administrador" papel (ou equivalente) pode ver 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 próxima seção.
Registrar usuários na interface do Airflow
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. Para controlar a função dos usuários recém-registrados, substitua essa opção de configuração do Airflow por um valor diferente.
Se não for especificada, a função de registro padrão será Op
em ambientes com
Airflow 2.
Em ambientes com o Airflow 1.10.*, o papel de registro padrão é Admin
.
As etapas a seguir são recomendadas para criar uma configuração papel básico para na interface do Airflow:
Airflow 2
Os administradores do ambiente abrem a interface do Airflow para o contêiner de nuvem.
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 papelAdmin
, 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
Substitua:
ENVIRONMENT_NAME
pelo nome do ambienteLOCATION
pela região em que o ambiente está localizado;USER_EMAIL
pelo e-mail de uma conta de usuário.
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
Os administradores do ambiente abrem a interface do Airflow para o ambiente recém-criado, em que são registrados automaticamente com o papel
Admin
.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 outra função que não seja de administradorOs administradores agora podem configurar o controle de acesso da interface do Airflow para novos usuários, incluindo: concedendo o papel
Admin
a outros usuários.
Pré-registrar usuários
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 adicionando 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 Corresponder 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 atual (no momento do primeiro login) identificados pelo endereço de e-mail. A relação entre Identidades do Google (endereços de e-mail) e contas de usuário (IDs de usuário) não for corrigido. Não é possível fazer o pré-registro de Grupos do Google.
Para pré-registrar usuários, use a interface do Airflow ou execute um comando da CLI do Airflow pela CLI do Google Cloud.
Para fazer o pré-registro de um usuário com um papel personalizado pela Google Cloud CLI, faça o seguinte: 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 ambienteLOCATION
: a região em que o ambiente está localizadoROLE
: um papel do Airflow para o usuário, por exemplo,Op
.USER_EMAIL
: o endereço de e-mail do usuárioFIRST_NAME
eLAST_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ão registrados de novo automaticamente na próxima vez que acessarem a interface do Airflow. Para
revogar o acesso a toda a interface do Airflow, remova a permissão composer.environments.get
da política de permissão do projeto.
Também é possível mudar a função do usuário para "Público", o 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 uma função personalizada do Airflow para cada subpasta diretamente na pasta /dags
e concede a essa função acesso ao nível do DAG a todas as DAGs que têm o arquivo de origem armazenado na respectiva subpasta. Isso
simplifica o gerenciamento de 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 forma automatizada de configurar e as permissões no nível do DAG. Assim, pode causar conflitos com Outros mecanismos do Airflow que concedem permissões no nível do DAG:
- Atribuir manualmente permissões do DAG a papéis.
- Atribuir DAGs a papéis usando a propriedade
access_control
em um DAG.
Para evitar esses conflitos, a ativação do Registro de funções por pasta também muda o comportamento desses mecanismos.
No Airflow 1, a possibilidade de usar esses mecanismos fica desativada quando O registro de papéis por pasta está ativado. Todas as permissões no nível do DAG o gerenciamento ocorre somente por meio do Registro de papéis por pasta.
No Airflow 2:
- É possível conceder acesso do DAG a papéis pela propriedade
access_control
definida no código-fonte do DAG. - Conceder manualmente permissões do DAG (por meio da interface do Airflow ou CLI gcloud) podem causar conflitos. Por exemplo, se você conceder manualmente permissões no nível do DAG a um papel por pasta, esses permissões podem ser removidas ou substituídas quando o processador de DAG sincroniza um DAG. Recomendamos que você não conceda permissões do DAG manualmente.
- Os papéis têm uma união de permissões de acesso ao DAG registradas por pasta
Registro de funções e definidos na propriedade
access_control
de ao 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. Eles não podem ser acessados com qualquer papel por pasta. Outra opção
como Administrador, Op, Usuário ou qualquer papel personalizado com permissão
acessá-los pela interface do Airflow e do DAG.
Se você fizer o upload de DAGs para subpastas com nomes que correspondem a funções integradas do Airflow e funções criadas pelo Cloud Composer, as permissões para DAGs nessas subpastas ainda serão atribuídas a essas funções. Por exemplo, fazer upload de um
O DAG para a pasta /dags/Admin
concede permissões a esse DAG ao administrador
de rede. Os papéis integrados do Airflow incluem Administrador, Op, 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 ao processar DAGs
no programador do Airflow. Se houver mais de cem DAGs no seu
ambiente, talvez ocorra um
aumento no tempo de análise do DAG.
Se esse for o caso, recomendamos aumentar o [scheduler]max_threads
para um ambiente do Airflow 1 ou [scheduler]parsing_processes
para
Airflow 2.
Atribuir automaticamente DAGs a papéis por pasta
Para atribuir automaticamente DAGs a papéis por pasta:
Substitua a seguinte opção de configuração do Airflow:
Seção Chave Valor webserver
rbac_autoregister_per_folder_roles
True
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 têm acesso a nenhum DAG até que um administrador designe uma função com permissões para DAGs específicos nas contas.
UserNoDags e NoDags são papéis criados apenas pelo Cloud Composer quando o recurso Registro de papéis por pasta estiver ativado. Elas são equivalentes à função de usuário, mas sem acesso a DAGs. UserNoDags é criado no Airflow 2, e o papel NoDags é criado no Airflow 1.
No Airflow 2, substitua a seguinte configuração do Airflow opção:
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
Verifique se os usuários estão registrados no Airflow.
Atribua funções aos usuários usando uma destas abordagens:
- Permita que o Airflow crie automaticamente funções com base nas subpastas de DAGs e atribua usuários a essas funções.
- Criar papéis vazios para as subpastas de DAGs, com nomes de papéis correspondentes
o nome de uma subpasta e, em seguida, atribuir usuários a esses papéis. Por exemplo:
Na pasta
/dags/CustomFolder
, crie um papel com o nomeCustomFolder
.
Faça o upload de DAGs para subpastas com nomes que correspondem às funções atribuídas aos usuários. Essas subpastas precisam estar localizadas na pasta
/dags
no bucket do ambiente. O Airflow adiciona permissões aos DAGs em um para que apenas os usuários com o papel correspondente possam acessá-las usando a interface 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 especificar quais DAGs são visíveis para determinados grupos de usuários.
Para configurar permissões no nível do DAG na interface do Airflow:
- O administrador cria papéis vazios para agrupar DAGs.
- O administrador atribui os usuários às funções apropriadas.
- O administrador ou os usuários atribuem DAGs a funções.
- Na interface do Airflow, os usuários só podem ver os DAGs atribuídos ao grupo deles.
Os DAGs podem ser atribuídos aos papéis por meio de propriedades do DAG ou da interface do Airflow.
Como atribuir DAGs a papéis na interface do Airflow
Um administrador pode atribuir as permissões no nível do DAG necessárias a papéis apropriados na interface 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 DAG access_control
em um DAG, especificando
os papéis de agrupamento do DAG a que ele é atribuído.
Airflow 2
dag = DAG(
access_control={
'DagGroup': {'can_edit', 'can_read'},
},
...
)
Airflow 1
dag = DAG(
access_control={
'DagGroup': {'can_dag_edit', 'can_dag_read'},
},
...
)
Associar registros de auditoria na interface do Airflow aos usuários
Os registros de auditoria na interface do Airflow são mapeados para IDs numéricos das 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 conferir os registros de auditoria na página Browse > Audit Logs da interface do Airflow.
Airflow 1
No Airflow 1, é possível conferir os registros de auditoria na página Browse > Logs.
Uma entrada típica lista um ID numérico no campo Owner:
accounts.google.com:NUMERIC_ID
É possível mapear IDs numéricos para e-mails de usuários no
Segurança > Listar usuários. Esta página está disponível para
usuários com a função 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
- Substituir as opções de configuração do Airflow
- Visão geral da segurança
- Controle de acesso do Cloud Composer