Snowpark Container Services: considerações adicionais sobre serviços¶

Opções de configuração de credenciais¶

A Snowflake recomenda que os contêineres de aplicativo usem credenciais fornecidas pelo Snowflake para autenticação no Snowflake ao executar SQL. É possível usar outras credenciais conectando-se por meio de uma integração de acesso externo (External Access Integration, EAI), mas a conexão por meio de uma EAI considera que o serviço está sendo executado fora do Snowflake e usa uma conexão de internet para se conectar ao Snowflake.

You have three options to connect to Snowflake from a service container:

• Usar as credenciais de usuário de serviço fornecidas pelo Snowflake: o Snowflake fornece a cada serviço credenciais chamadas de «credenciais de serviço». Um serviço usa essas credenciais para se conectar ao Snowflake como usuário do serviço.

• Usar as credenciais de autor da chamada fornecidas pelo Snowflake (direitos do autor da chamada): quando você configura seu serviço com direitos do autor da chamada, o Snowflake também fornece credenciais para que o serviço se conecte ao Snowflake como o usuário que faz a chamada.

• Use other credentials: In this case, you use an external access integration (EAI) that allows your service to connect to Snowflake’s internet endpoint by using valid authentication credentials. This option requires an administrator to create the EAI, and then grant the USAGE privilege on the integration to the service owner role.

  Nota

  Se você usar integrações de acesso externo para acessar o Snowflake, poderá enviar informações potencialmente confidenciais pela Internet.

Para obter exemplos de código que usa vários drivers do Snowflake para se conectar ao Snowflake, consulte Amostras de conexão com o Snowflake.

SNOWFLAKE_ACCOUNT = os.getenv('SNOWFLAKE_ACCOUNT')
SNOWFLAKE_HOST = os.getenv('SNOWFLAKE_HOST')

def get_login_token():
  with open('/snowflake/session/token', 'r') as f:
    return f.read()

conn = snowflake.connector.connect(
  host = os.getenv('SNOWFLAKE_HOST'),
  account = os.getenv('SNOWFLAKE_ACCOUNT'),
  token = get_login_token(),
  authenticator = 'oauth'
)

ALTER USER my_user SET DEFAULT_SECONDARY_ROLES = ( 'ALL' );

-- Permissions to resolve the table's name.
GRANT CALLER USAGE ON DATABASE <db_name> TO ROLE <service_owner_role>;
GRANT CALLER USAGE ON SCHEMA <schema_name> TO ROLE <service_owner_role>;
-- Permissions to use a warehouse
GRANT CALLER USAGE ON WAREHOUSE <warehouse_name> TO ROLE <service_owner_role>;
-- Permissions to query the table.
GRANT CALLER SELECT ON TABLE T1 TO ROLE <service_owner_role>;

conn = snowflake.connector.connect(
  account = '<acct-name>',
  user = '<user-name>',
  password = '<password>'
)

Configuration of the database and schema context for executing SQL¶

Além de fornecer as credenciais, o Snowflake fornece o contexto de banco de dados e esquema no qual o serviço é criado. O código do contêiner pode usar essa informação para executar SQL no mesmo contexto de banco de dados e esquema que o serviço.

Esta seção explica dois conceitos:

• A lógica que o Snowflake usa para determinar o banco de dados e o esquema no qual criar seu serviço.

• O método pelo qual o Snowflake transmite essas informações aos seus contêineres, permitindo assim que o código do contêiner execute SQL no mesmo banco de dados e contexto de esquema.

O Snowflake usa o nome do serviço para determinar o banco de dados e o esquema no qual criar um serviço:

• Exemplo 1: nos seguintes comandos CREATE SERVICE e EXECUTE JOB SERVICE, o nome do serviço não especifica explicitamente um nome de banco de dados e esquema. O Snowflake cria o serviço e o serviço de trabalho no banco de dados e esquema atuais.

  -- Create a service.
  CREATE SERVICE test_service IN COMPUTE POOL ...
  
  -- Execute a job service.
  EXECUTE JOB SERVICE
    IN COMPUTE POOL tutorial_compute_pool
    NAME = example_job_service ...
  

  Copy

• Exemplo 2: nos seguintes comandos CREATE SERVICE e EXECUTE JOB SERVICE, o nome do serviço inclui um nome de banco de dados e esquema. Snowflake cria o serviço e serviço do trabalho no banco de dados (test_db) e esquema (test_schema) especificados, independentemente do esquema atual.

  -- Create a service.
  CREATE SERVICE test_db.test_schema.test_service IN COMPUTE POOL ...
  
  -- Execute a job service.
  EXECUTE JOB SERVICE
    IN COMPUTE POOL tutorial_compute_pool
    NAME = test_db.test_schema.example_job_service ...
  

  Copy

Quando o Snowflake inicia um serviço, ele fornece informações de banco de dados e esquema para os contêineres em execução usando as seguintes variáveis de ambiente:

• SNOWFLAKE_DATABASE

• SNOWFLAKE_SCHEMA

O código do contêiner pode usar variáveis de ambiente no código de conexão para determinar qual banco de dados e esquema usar, conforme mostrado neste exemplo:

conn = snowflake.connector.connect(
  host = os.getenv('SNOWFLAKE_HOST'),
  account = os.getenv('SNOWFLAKE_ACCOUNT'),
  token = get_login_token(),
  authenticator = 'oauth',
  database = os.getenv('SNOWFLAKE_DATABASE'),
  schema = os.getenv('SNOWFLAKE_SCHEMA')
)

Exemplo

No Tutorial 2, você cria um serviço de trabalho do Snowflake que se conecta ao Snowflake e executa instruções SQL. As etapas a seguir resumem como o código do tutorial usa as variáveis de ambiente:

1. Na configuração comum (consulte a seção Configuração comum), você cria recursos, incluindo um banco de dados e um esquema. Você também define o banco de dados e o esquema atuais para a sessão:

   USE DATABASE tutorial_db;
   ...
   USE SCHEMA data_schema;
   

   Copy

2. Depois de criar um serviço de trabalho (executando EXECUTE JOB SERVICE), o Snowflake inicia o contêiner e define as seguintes variáveis de ambiente no contêiner para o banco de dados e o esquema atuais da sessão:

   • SNOWFLAKE_DATABASE é definido como “TUTORIAL_DB”

   • SNOWFLAKE_SCHEMA é definido como “DATA_SCHEMA”

3. O código do trabalho (consulte main.py no Tutorial 2) lê estas variáveis de ambiente:

   SNOWFLAKE_DATABASE = os.getenv('SNOWFLAKE_DATABASE')
   SNOWFLAKE_SCHEMA = os.getenv('SNOWFLAKE_SCHEMA')
   

   Copy

4. O código do trabalho define o banco de dados e o esquema como o contexto no qual executar as instruções SQL (função run_job() em main.py):

   {
      "account": SNOWFLAKE_ACCOUNT,
      "host": SNOWFLAKE_HOST,
      "authenticator": "oauth",
      "token": get_login_token(),
      "warehouse": SNOWFLAKE_WAREHOUSE,
      "database": SNOWFLAKE_DATABASE,
      "schema": SNOWFLAKE_SCHEMA
   }
   ...
   

   Copy

   Nota

   SNOWFLAKE_ACCOUNT, SNOWFLAKE_HOST, SNOWFLAKE_DATABASE, SNOWFLAKE_SCHEMA são variáveis de ambiente que o Snowflake gera para o contêiner do aplicativo, mas SNOWFLAKE_WAREHOUSE não é (o código do aplicativo do Tutorial 2 criou essa variável porque o Snowflake não passa um nome de warehouse para um contêiner).

Como especificar o warehouse para seu contêiner¶

Se seu serviço se conectar ao Snowflake para executar uma consulta em um warehouse do Snowflake, você terá as seguintes opções para especificar um warehouse:

• Especifique um warehouse no código do seu aplicativo. Especifique um warehouse como parte da configuração da conexão ao iniciar uma sessão do Snowflake para executar consultas no seu código. Para obter um exemplo, consulte Tutorial 2.

• Specify a default warehouse when creating a service. Specify the optional QUERY_WAREHOUSE parameter in the CREATE SERVICE or EXECUTE JOB SERVICE command to provide a default warehouse. If your application code doesn’t provide a warehouse as part of connection configuration, Snowflake uses the default warehouse. Use the ALTER SERVICE command to change the default warehouse.

  Nota

  O warehouse especificado usando o parâmetro QUERY_WAREHOUSE é o padrão somente para o usuário do serviço. Quando o serviço se conecta ao Snowflake em nome de outro usuário, no contexto do cenário de direitos do autor da chamada, o Snowflake usa o warehouse padrão do usuário.

If you specify a warehouse by using both methods, the warehouse that is specified in the application code is used.

Access service user query history¶

You can find queries executed by your service as the service user by filtering the Exibição QUERY_HISTORY or QUERY_HISTORY function where user_type is SNOWFLAKE_SERVICE.

Exemplo 1: Busca de consultas executadas por um serviço.

SELECT *
FROM snowflake.account_usage.query_history
WHERE user_type = 'SNOWFLAKE_SERVICE'
AND user_name = '<service_name>'
AND user_database_name = '<service_db_name>'
AND user_schema_name = '<service_schema_name>'
order by start_time;

Na cláusula WHERE:

• user_name = '<service_name>': você especifica o nome do serviço como o nome do usuário porque um serviço executa consultas como o usuário do serviço, e o nome do usuário do serviço é o mesmo que o nome do serviço.

• user_type = 'SNOWFLAKE_SERVICE' e user_name = '<service_name>': isso limita o resultado da consulta para recuperar apenas as consultas executadas por um serviço.

• user_database_name e user_schema_name: para um usuário do serviço, esses são o banco de dados e o esquema do serviço.

Você pode obter os mesmos resultados chamando a função QUERY_HISTORY.

SELECT *
FROM TABLE(<service_db_name>.information_schema.query_history())
WHERE user_database_name = '<service_db_name>'
AND user_schema_name = '<service_schema_name>'
AND user_type = 'SNOWFLAKE_SERVICE'
AND user_name = '<service_name>'
order by start_time;

Na cláusula WHERE:

• user_type = 'SNOWFLAKE_SERVICE' e user_name = '<service_name>' limitam o resultado da consulta para recuperar apenas as consultas executadas por um serviço.

• Os nomes user_database_name e user_schema_name (para um usuário de serviço) são o banco de dados e o esquema do serviço.

Exemplo 2: buscar consultas executadas por serviços e as informações de serviço correspondentes.

SELECT query_history.*, services.*
FROM snowflake.account_usage.query_history
JOIN snowflake.account_usage.services
ON query_history.user_name = services.service_name
AND query_history.user_schema_id = services.service_schema_id
AND query_history.user_type = 'SNOWFLAKE_SERVICE'

A consulta une as exibições QUERY_HISTORY e SERVICES para recuperar informações sobre as consultas e os serviços que executaram as consultas. Observe o seguinte:

• Para consultas executadas por serviços, query_history.user_name é o nome do usuário do serviço, que é o mesmo que o nome do serviço.

• A consulta une as exibições usando os IDs de esquema (não o nome do esquema) para garantir que você se refira ao mesmo esquema, porque se você remover e recriar um esquema, o ID do esquema será alterado, mas o nome permanecerá o mesmo.

Você pode adicionar filtros opcionais à consulta. Por exemplo:

• Filtre query_history para recuperar apenas serviços que executaram consultas específicas.

• Filtre services para recuperar apenas consultas executadas por serviços específicos.

Exemplo 3: Para cada serviço, busque informações do usuário do serviço.

SELECT services.*, users.*
FROM snowflake.account_usage.users
JOIN snowflake.account_usage.services
ON users.name = services.service_name
AND users.schema_id = services.service_schema_id
AND users.type = 'SNOWFLAKE_SERVICE'

A consulta une as exibições SERVICES e USERS no esquema ACCOUNT_USAGE para recuperar serviços e informações do usuário do serviço. Observe o seguinte:

• Quando um serviço executa consultas, ele as executa como usuário do serviço e o nome do usuário do serviço é o mesmo que o nome do serviço. Portanto, você especifica a condição de junção: users.name = services.service_name.

• Os nomes de serviço são exclusivos apenas dentro de um esquema. Portanto, a consulta especifica a condição de junção (users.schema_id = services.service_schema_id) para garantir que cada usuário do serviço seja correspondido ao serviço específico ao qual pertence (e não a qualquer outro serviço com o mesmo nome em execução em esquemas diferentes).

Tempo limite da conexão de entrada¶

Os pontos de extremidade de entrada têm um tempo limite de 90 segundos. Se não houver atividade em uma conexão com um ponto de extremidade de entrada por 90 segundos, o Snowflake encerrará a conexão. Caso seu aplicativo precise de uma conexão por mais tempo, use a sondagem ou o WebSockets.

Logout de autenticação do navegador Web de entrada¶

Se estiver criando um aplicativo Web executado como um serviço, você tem a opção de permitir que os usuários façam logout do aplicativo, direcionando-os para /sfc-endpoint/logout.

Depois de fazer o logout, o usuário precisará se autenticar novamente no Snowflake para acessar o ponto de extremidade público do serviço.

Entrada e segurança de aplicativos da web¶

Você pode criar um serviço Snowpark Container Services para hospedagem na web usando o suporte do ponto de extremidade público (entrada de rede). Para maior segurança, Snowflake emprega um serviço de proxy para monitorar solicitações recebidas de clientes para o seu serviço e respostas de saída do seu serviço para os clientes. Esta seção explica o que o proxy faz e como ele afeta um serviço implantado no Snowpark Container Services.

Por exemplo:

• O proxy não encaminha uma solicitação HTTP recebida se a solicitação usar um método HTTP banido.

• O proxy envia uma resposta 403 ao cliente se o cabeçalho Content-Type na resposta indicar que a resposta contém um executável.

Além disso, o proxy também pode injetar novos cabeçalhos e alterar os cabeçalhos existentes na solicitação e na resposta, tendo em mente o seu contêiner e a segurança de dados.

Por exemplo, ao receber uma solicitação, seu serviço pode enviar HTML, JavaScript, CSS e outros conteúdos de uma página da Web para o navegador do cliente na resposta. A página da web no navegador faz parte do seu serviço, atuando como interface do usuário. Por motivos de segurança, se o seu serviço tiver restrições (como uma restrição ao estabelecimento de conexões de rede com outros sites), você também poderá querer que a página da Web do seu serviço tenha as mesmas restrições.

Por padrão, os serviços têm permissões limitadas para acessar a Internet. O navegador também deve restringir o acesso do aplicativo cliente à Internet e o possível compartilhamento de dados na maioria dos casos. Se você configurar uma integração de acesso externo (EAI) para permitir que seu serviço acesse example.com (consulte Configuração da saída da rede), a página da Web do seu serviço também deverá poder acessar example.com por meio de seu navegador.

O proxy Snowflake aplica as mesmas restrições de rede ao serviço e à página da web adicionando um cabeçalho Content-Security-Policy (CSP) na resposta. Por padrão, o proxy adiciona uma linha de base CSP na resposta para proteção contra ameaças de segurança comuns. A segurança do navegador é um esforço máximo para equilibrar funcionalidade e segurança. É uma responsabilidade compartilhada para garantir que essa linha de base seja apropriada para seu caso de uso. Além disso, se o seu serviço estiver configurado para usar um EAI, o proxy aplicará as mesmas regras de rede de EAI a CSP para a página da web. Este CSP permite que a página da web no navegador acesse os mesmos sites que o serviço pode acessar.

O Snowflake oferece o suporte CORS que você configura na especificação do serviço.

O proxy do Snowflake retorna as configurações do CORS definidas na especificação do serviço. Observe que o proxy remove todos os cabeçalhos do CORS retornados pelo serviço.

Os seguintes cabeçalhos do CORS são definidos por padrão:

• O cabeçalho Access-Control-Expose-Headers sempre informa os seguintes nomes de cabeçalho, além dos cabeçalhos configurados na especificação de serviço para o ponto de extremidade.

  • X-Frame-Options

  • Cross-Origin-Opener-Policy

  • Cross-Origin-Resource-Policy

  • X-Content-Type-Options

  • Cross-Origin-Embedder-Policy

  • Content-Security-Policy-Report-Only

  • Content-Security-Policy

• Access-Control-Max-Age é definido para duas horas.

• Access-Control-Allow-Credentials é definido como verdadeiro.

Além disso, o Snowflake define o cabeçalho Vary com o valor Origin para indicar ao navegador que, com base no valor de Origin, o valor de Access-Control-Allow-Origin pode ser diferente.

O cabeçalho Authorization é necessário para fazer a solicitação CORS. Você pode especificar um token de acesso programático (PAT) neste cabeçalho (Authorization: "Snowflake Token=\"${patToken}\""). Para obter informações sobre como gerar um token de acesso programático, consulte Uso de tokens de acesso programático para autenticação.

As seções a seguir explicam como o proxy Snowflake lida com solicitações de entrada para o seu serviço e modifica as respostas de saída do seu serviço para os clientes.

Considerações sobre ingresso e CORS¶

Por padrão, os navegadores impedem que os aplicativos Web hospedados em um servidor enviem solicitações a outro servidor com um nome de host diferente. Por exemplo, se você hospedar um aplicativo Web fora do Snowpark Container Services que precise interagir com um serviço de backend implantado no Snowpark Container Services, essa restrição se aplica.

O CORS (Cross-Origin Resource Sharing ou Compartilhamento de recursos entre origens) permite que um serviço do Snowpark Container Services comunique aos navegadores que é permitido fazer solicitações de aplicativos Web hospedados fora do seu ambiente. Você pode configurar cada ponto de extremidade público para especificar como ele responde às solicitações de preflight do CORS e às solicitações padrão.

O proxy do Snowflake sempre substitui os seguintes cabeçalhos de resposta:

• Access-Control-Allow-Origin

• Access-Control-Allow-Methods

• Access-Control-Allow-Headers

• Access-Control-Expose-Headers

• Access-Control-Max-Age

• Access-Control-Allow-Credentials

O proxy do Snowflake não inclui nenhum desses cabeçalhos do CORS na resposta quando um dos seguintes itens for verdadeiro:

• O CORS não está configurado para o ponto de extremidade do serviço. Ou seja, não há corsSettings na especificação do serviço

• O CORS está configurado para o ponto de extremidade do serviço, mas o cabeçalho Origin na solicitação não corresponde ao campo Access-Control-Allow-Origin especificado na especificação do serviço

Na especificação do serviço, você pode definir as configurações do CORS para cada ponto de extremidade público. Quando o cabeçalho origin na solicitação corresponde ao campo Access-Control-Allow-Origin especificado para o ponto de extremidade na especificação, o proxy inclui na resposta os cabeçalhos do CORS definidos na especificação, com os seguintes ajustes:

• Access-Control-Allow-Origin: retorna o cabeçalho Origin da solicitação.

• Access-Control-Expose-Headers: mescla a lista de cabeçalhos permitidos que você configurou com esses cabeçalhos sempre expostos: X-Frame-Options, Cross-Origin-Opener-Policy, Cross-Origin-Resource-Policy, X-Content-Type-Options, Cross-Origin-Embedder-Policy, Content-Security-Policy-Report-Only, Content-Security-Policy.

• Access-Control-Max-Age: é definido para duas horas.

• Access-Control-Allow-Credentials: é definido como verdadeiro.

Considerações sobre ingresso e SSO¶

Ao acessar o ponto de extremidade público pela Internet, você pode descobrir que a autenticação por nome de usuário/senha funciona, mas SSO resulta em uma página em branco ou no erro: «A integração do clienteOAuth com o ID do cliente fornecido não foi encontrada.»

Isso acontece quando você está usando o estilo antigo de autenticação federada (SSO) com o Snowflake em vez da versão mais recente de integração de segurança, conforme explicado em Configuração do Snowflake para usar a autenticação federada. Faça o seguinte para verificar:

1. Execute a seguinte consulta:

   SHOW PARAMETERS LIKE 'SAML_IDENTITY_PROVIDER' IN ACCOUNT;
   

   Copy

   Se esse parâmetro estiver definido, então, em algum momento, você estava usando a autenticação federada antiga.

2. Se o parâmetro anterior foi definido, execute a seguinte consulta para verificar se você tem uma integração de segurança SAML:

   SHOW INTEGRATIONS
     ->> SELECT * FROM $1 WHERE "type" = 'SAML2';
   

   Copy

   Se você não tiver nenhuma integração do tipo SAML2, então está usando a versão antiga de autenticação federada.

Nesse caso, a solução é migrar da autenticação federada antiga para a nova autenticação federada da integração. Para obter mais informações, consulte Migração para uma integração de segurança SAML2.

Saída da rede usando conectividade privada¶

Em vez de rotear a saída da rede pela Internet pública, você pode optar por direcionar o tráfego de saída do seu serviço por meio de um ponto de extremidade de conectividade privada.

Primeiro, você precisa criar o ponto de extremidade de conectividade privada em sua conta do Snowflake. Em seguida, configure uma regra de rede para permitir que o tráfego de saída use a conectividade privada. O processo de configuração de uma integração de acesso externo (EAI) permanece o mesmo descrito na seção anterior.

Por exemplo, se você quiser habilitar o acesso de saída da Internet do seu serviço a um bucket S3 Amazon por meio de conectividade privada, faça o seguinte:

1. Habilite a conectividade do link privado para o serviço de ponto de extremidade autônomo (Amazon S3). Para obter instruções passo a passo, consulte AWS Private Link para Amazon S3.

2. Chame a função do sistema SYSTEM$PROVISION_PRIVATELINK_ENDPOINT para provisionar um ponto de extremidade de conectividade privada em seu Snowflake VNet. Isso permite que o Snowflake se conecte ao serviço externo (neste exemplo, o Amazon S3) usando conectividade privada.

   USE ROLE ACCOUNTADMIN;
   
   SELECT SYSTEM$PROVISION_PRIVATELINK_ENDPOINT(
     'com.amazonaws.us-west-2.s3',
     '*.s3.us-west-2.amazonaws.com'
   );
   

   Copy

3. Na conta do provedor de nuvem, aprove o ponto de extremidade. Neste exemplo, para a Amazon AWS, consulte Como aceitar ou rejeitar solicitações de conexão na documentação do AWS. Além disso, para aprovar o ponto de extremidade no Azure, consulte a documentação do Azure.

4. Use o comando CREATE NETWORK RULE para criar uma regra de rede de saída que especifique os destinos externos aos quais você deseja permitir o acesso.

   CREATE OR REPLACE NETWORK RULE private_link_network_rule
     MODE = EGRESS
     TYPE = PRIVATE_HOST_PORT
     VALUE_LIST = ('<bucket-name>.s3.us-west-2.amazonaws.com');
   

   Copy

   O valor do parâmetro TYPE é definido como PRIVATE_HOST_PORT. Isso indica que a regra de rede permite que o tráfego de rede de saída use a conectividade privada.

5. As demais etapas para criar uma EAI e usá-la para criar um serviço são as mesmas explicadas na seção anterior (consulte Configuração da saída da rede).

Para obter mais informações sobre como trabalhar com pontos de extremidade de conectividade privada, consulte o seguinte:

• Gerenciamento de pontos de extremidade de conectividade privada: AWS

• Gerenciar pontos de extremidade de conectividade privada: Azure

• Gerenciamento de pontos de extremidade de conectividade privada: Google Cloud

Especificando segredos Snowflake¶

Especifique um segredo Snowflake por nome ou referência (a referência é aplicável somente no cenário com Native Applications):

• Passe o segredo Snowflake por nome: É possível passar um nome secreto como valor do campo snowflakeSecret.

  ...
  secrets:
  - snowflakeSecret:
      objectName: '<secret-name>'
    <other info about where in the container to copy the secret>
    ...
  

  Copy

  Observe que você pode opcionalmente especificar <secret-name> diretamente como o valor snowflakeSecret.

• Passe o segredo Snowflake por referência: Ao usar o Snowpark Container Services para criar um Native App (um aplicativo com contêineres), o produtor e os consumidores do aplicativo usam contas Snowflake diferentes. Em alguns contextos, um Snowflake Native App instalado precisa acessar objetos secretos existentes na conta do consumidor que existem fora do objeto APPLICATION. Nesse caso, os desenvolvedores podem usar a sintaxe da especificação “segredos por referência” para manipular credenciais, conforme mostrado:

  containers:
  - name: main
    image: <url>
    secrets:
    - snowflakeSecret:
        objectReference: '<reference-name>'
      <other info about where in the container to copy the secret>
  

  Copy

  Observe que a especificação usa objectReference em vez de objectName para fornecer um nome de referência de segredo.

Especificação do posicionamento dos segredos dentro do contêiner¶

É possível dizer ao Snowflake para colocar os segredos nos contêineres como variáveis de ambiente ou gravá-los em arquivos de contêiner locais.

containers:
- name: main
  image: <url>
  secrets:
  - snowflakeSecret: <secret-name>
    secretKeyRef: username | password | secret_string |  'access_token'
    envVarName: '<env-variable-name>'

CREATE SECRET testdb.testschema.my_secret_object
  TYPE = password
  USERNAME = 'snowman'
  PASSWORD = '1234abc';

containers:
- name: main
  image: <url>
  secrets:
  - snowflakeSecret: testdb.testschema.my_secret_object
    secretKeyRef: username
    envVarName: LOGIN_USER
  - snowflakeSecret: testdb.testschema.my_secret_object
    secretKeyRef: password
    envVarName: LOGIN_PASSWORD

CREATE SECRET testdb.testschema.my_secret
  TYPE=generic_string
  SECRET_STRING='
       some_magic: config
  ';

containers:
- name: main
  image: <url>
  secrets:
  - snowflakeSecret: testdb.testschema.my_secret
    secretKeyRef: secret_string
    envVarName: GENERIC_SECRET

containers:
- name: <name>
  image: <url>
  ...
  secrets:
  - snowflakeSecret: <snowflake-secret-name>
    directoryPath: '<local directory path in the container>'

CREATE SECRET testdb.testschema.my_secret_object
  TYPE = password
  USERNAME = 'snowman'
  PASSWORD = '1234abc';

containers:
- name: main
  image: <url>
  secrets:
  - snowflakeSecret: testdb.testschema.my_secret_object
    directoryPath: '/usr/local/creds'

CREATE SECRET testdb.testschema.my_secret
  TYPE=generic_string
  SECRET_STRING='
       some_magic: config
  ';

containers:
- name: main
  image: <url>
  secrets:
  - snowflakeSecret: testdb.testschema.my_secret
    directoryPath: '/usr/local/creds'

CREATE SECRET testdb.testschema.oauth_secret
  TYPE = OAUTH2
  OAUTH_REFRESH_TOKEN = '34n;vods4nQsdg09wee4qnfvadH'
  OAUTH_REFRESH_TOKEN_EXPIRY_TIME = '2023-12-31 20:00:00'
  API_AUTHENTICATION = my_integration;

containers:
- name: main
  image: <url>
  secrets:
  - snowflakeSecret: testdb.testschema.oauth_secret
    directoryPath: '/usr/local/creds'