Usar políticas de recursos para limitar os objetos que um aplicativo pode criar¶

Sobre as políticas de recursos¶

Se um aplicativo estiver configurado para usar a concessão automatizada de privilégios, o aplicativo pode solicitar os seguintes privilégios:

• EXECUTE TASK

• EXECUTE MANAGED TASK

• CREATE WAREHOUSE

• CREATE COMPUTE POOL

• BIND SERVICE ENDPOINT

• CREATE DATABASE

• CREATE EXTERNAL ACCESS INTEGRATION

Se o aplicativo estiver configurado para usar esses privilégios, eles não poderão ser revogados por consumidores após a instalação do aplicativo. No entanto, os administradores de consumidores podem usar políticas de recursos para limitar os objetos que um aplicativo pode criar na conta do consumidor.

Por exemplo, se um consumidor não quiser que um aplicativo crie warehouses ou pools de computação, um administrador de conta do consumidor poderá criar uma política de recurso que proíbe um aplicativo específico ou todos os aplicativos de criar warehouses ou pools de computação.

As políticas de recursos permitem que os consumidores impeçam um aplicativo de criar ou usar os seguintes objetos:

• COMPUTE POOLS

• DATABASES

• TASKS

• WAREHOUSES

Fluxo de trabalho¶

Este é o fluxo de trabalho geral para usar políticas de recursos para limitar os objetos que um aplicativo pode criar:

1. Ver a listagem do aplicativo para determinar os privilégios que o aplicativo está solicitando.

2. Se houver algum objeto que você queira restringir, crie uma política de recursos para bloquear esses objetos.

   Para obter mais informações, consulte Criar uma nova política de recursos.

3. Aplicar a política de recursos à conta ou a um objeto específico.

   Para obter mais informações, consulte Atribuir uma política de recursos no nível da conta e Aplicar uma política de recursos a um aplicativo.

Considerações sobre a replicação ao usar políticas de recursos¶

As referências de política de recursos no nível da conta são replicadas quando o banco de dados que contém a política é especificado, por exemplo, definindo ALLOWED_DATABASES = policy_db em um grupo de replicação ou de failover.

Se a conta já tiver sido replicada para uma de destino, o administrador da conta do consumidor deve fazer o seguinte:

1. Atualizar o grupo de replicação ou failover na conta de origem para incluir os bancos de dados e os tipos de objetos necessários para replicar a política de recursos.

2. Executar uma operação para atualizar a conta de destino.

Se você tiver uma política de recursos definida na conta e não atualizar o grupo de replicação ou failover para incluir o policy_db com a política, isso criará uma referência pendente na conta de destino. Isso significa que o Snowflake não consegue localizar a política na conta de destino porque o nome totalmente qualificado da política aponta para o banco de dados na conta de origem. O resultado é que a conta ou os usuários de destino na conta de destino não são obrigados a cumprir a política de recurso.

Para replicar com sucesso uma política de recurso, verifique se o grupo de replicação ou failover inclui os tipos de objetos e bancos de dados necessários para evitar uma referência pendente.

Para obter mais informações, consulte Considerações sobre a replicação.

Precedência da política de recursos¶

Os consumidores podem aplicar uma política de recursos a todos os aplicativos de uma conta ou a um aplicativo específico. Se houver políticas de recursos aplicadas a mais de um deles, a política de recursos mais específica substituirá as políticas de recursos mais gerais. O seguinte resume a ordem de precedência:

Conta:

As políticas de recursos aplicadas a uma conta são as políticas de recursos mais gerais. Elas são substituídas por políticas de recursos aplicadas a um objeto específico, por exemplo, um aplicativo

Objeto:

As políticas de recursos aplicadas a um objeto específico substituem as políticas de recursos aplicadas à conta.

Os consumidores podem usar essa precedência para ajustar os objetos que um aplicativo pode criar em sua conta. Por exemplo, um consumidor pode aplicar uma política de recursos no nível da conta que proíba todos os aplicativos da conta de criar um banco de dados. Se um aplicativo tentar criar um banco de dados durante a instalação, a instalação falhará.

No entanto, os consumidores também podem criar uma política de recursos sem restrições e aplicar essa política de recursos a um aplicativo específico. Esse aplicativo teria permissão para criar um banco de dados.

Para obter mais informações, consulte Criar uma nova política de recursos.

Privilégios necessários para usar as políticas de recursos¶

A tabela a seguir descreve os privilégios necessários para criar e usar políticas de recursos:

Como trabalhar com políticas de recursos¶

Os consumidores podem usar Snowsight ou SQL para gerenciar o ciclo de vida de uma política de recursos.

CREATE DATABASE feature_policy_db;
CREATE SCHEMA sch;
CREATE FEATURE POLICY block_create_db_policy
  BLOCKED_OBJECT_TYPES_FOR_CREATION = (DATABASE);

CREATE FEATURE POLICY block_nothing_policy
  BLOCKED_OBJECT_TYPES_FOR_CREATION = ();

ALTER ACCOUNT
  SET FEATURE POLICY feature_policy_db.sch.block_create_db_policy
  FOR ALL APPLICATIONS;

CREATE APPLICATION hello_snowflake_app
  WITH FEATURE POLICY = feature_policy_db.block_create_db_policy;

ALTER APPLICATION hello_snowflake_app
  SET FEATURE POLICY feature_policy_db.block_create_db_policy;

ALTER ACCOUNT UNSET FEATURE POLICY FOR ALL APPLICATIONS;

ALTER APPLICATION FEATURE_POLICY_TEST_APP UNSET FEATURE POLICY;

DROP FEATURE POLICY block_create_db_policy;

Visualizar informações sobre políticas de recursos¶

Para visualizar as políticas de recursos em uma conta na qual você tem privilégios de acesso, use o comando SHOW FEATURE POLICIES:

SHOW FEATURE POLICIES ON ACCOUNT;

Para visualizar as políticas de recursos aplicadas a um aplicativo, use o seguinte comando:

SHOW FEATURE POLICIES ON APPLICATION hello_snowflake_app;

Para ver informações sobre uma política de recursos específica, use DESCRIBE FEATURE POLICY, conforme mostrado no exemplo a seguir:

DESCRIBE FEATURE POLICY feature_policy_db.block_create_db_policy;