Snowpark Container Services: Ingress, Egress, Secrets and Monitoring

1.Ingress: private by default, public through a proxy

Every port a service listens on is declared as an endpoint in the specification. By default, endpoints are private. Only service functions and other services can call them. Setting public: true gives the endpoint a unique Snowflake hostname reachable from the internet. Because this is a privileged operation, the owner role must hold BIND SERVICE ENDPOINT on the account.

endpoints:
- name: <endpoint name>
  port: <port number>
  protocol : < TCP / HTTP >
  public: true

Public traffic never reaches your container directly. A Snowflake proxy sits in front of the service and filters both requests and responses. Idle connections are closed after 90 seconds, and users can sign out at /sfc-endpoint/logout, after which they have to authenticate to Snowflake again.

Sources1

2.Egress: network rules and external access integrations

Outbound access is the reverse problem. By default, services have only limited internet access. To allow a destination, an administrator creates one or more egress network rules and gathers them, together with any secrets, into an external access integration (EAI). The service is then configured to use that EAI. Any destination that no rule allows is denied. Snowflake gives ACCOUNTADMIN as an example of a role that can create an EAI. Creating a network rule requires CREATE NETWORK RULE on the schema.

CREATE OR REPLACE NETWORK RULE google_apis_network_rule
  MODE =  ? 
  TYPE = HOST_PORT
  VALUE_LIST = ('translation.googleapis.com');

SPCS adds some limits. VALUE_LIST needs full host names, and wildcards such as *.googleapis.com are rejected. If you leave out the port, it defaults to 443. SPCS accepts only rules for ports 22, 80, 443 and 1024 and above. The EAI also applies to the browser: for a public web app, the proxy copies the EAI's network rules into the page's Content-Security-Policy, so the page can reach only the sites the service can reach.

Sources12

3.Keeping secrets out of the YAML

The containers.env field looks like an easy place for an API key, but every process in the container can read those variables, and the specification itself is metadata. Snowflake asks customers not to put personal, sensitive or regulated data there. The right approach is to store the credential in a Snowflake secret object and reference it from the specification.

    secrets:                                # optional list
      - snowflakeSecret:
          objectName: <object-name>         # specify this or objectReference
          objectReference: <reference-name> # specify this or objectName
        directoryPath: <path>               # specify this or envVarName
        envVarName: <name>                  # specify this or directoryPath
        secretKeyRef: username | password | secret_string # specify only with envVarName

snowflakeSecret names the secret with objectName. In a Native App with containers, it uses objectReference instead. You then choose where the value appears in the container: envVarName puts one key, chosen with secretKeyRef (username, password or secret_string), into an environment variable, and directoryPath writes the secret to files. The service's owner role needs READ on every secret it references, so access to secrets is controlled by grants rather than by whoever can read the YAML.

Sources3

4.Monitoring: container logs and compute pool usage

Unless you opt out, Snowflake collects whatever containers write to stdout and stderr into the account's event table. spec.logExporters chooses which streams are kept (all, stderr only, or none), and the LOG_LEVEL parameter on CREATE SERVICE or ALTER SERVICE sets the severity. Logs written as JSON with a body key are stored as structured records. Any other output goes into the value column. Anything the code prints ends up in a table, so do not log secrets.

SELECT TIMESTAMP, RESOURCE_ATTRIBUTES, RECORD_ATTRIBUTES, VALUE
FROM <current_event_table_for_your_account>
WHERE timestamp > dateadd(hour, -1, current_timestamp())
AND RESOURCE_ATTRIBUTES:"snow.service.name" = '<service_name>'
AND RECORD_TYPE = 'LOG'
ORDER BY timestamp DESC
LIMIT 10;

For compute pools, the exam guide mentions a SERVICE_USAGE_HISTORY view. The documentation in these sources does not describe a view by that name. The pool-level view it does document is ACCOUNT_USAGE.SNOWPARK_CONTAINER_SERVICES_HISTORY. It returns hourly credits for each compute pool over 365 days, with up to three hours of latency, and its IS_EXCLUSIVE and APPLICATION_NAME columns show pools created for applications. An unexpected rise in a pool's credits is a signal worth investigating. Every monitoring method still requires the right privileges on the services, jobs and compute pools involved.

Sources45

Exam traps

Each one states something that sounds right. Open it to see what is actually true.

1. 1.A service endpoint can be reached from the internet unless you explicitly block it.Why is that wrong?

   Endpoints are private by default. Only service functions and other services can call them until public: true is set, and that requires BIND SERVICE ENDPOINT.

   Covered in Ingress: private by default, public through a proxy

2. 2.To let someone read one service's logs, you have to grant them access to the account's event table.Why is that wrong?

   <service_name>!SPCS_GET_LOGS needs only the owner role or MONITOR on that service, so the rest of the event table stays restricted.

   Covered in Monitoring: container logs and compute pool usage

3. 3.Putting an API key in containers.env is safe because only the main process reads it.Why is that wrong?

   Every process in the container can read env values, and specification metadata should not contain sensitive data. Use containers.secrets with a Snowflake secret instead.

   Covered in Keeping secrets out of the YAML

Practise it for real

Find and read a service's container logs while using as little access as possible

1. 1.Run SHOW PARAMETERS LIKE 'event_table' IN ACCOUNT;

   Why: Container logs go to the account's active event table, so you need to know which table that is.

   You should see: The EVENT_TABLE parameter value, which is the fully qualified name of the active event table.

2. 2.As a role with MONITOR on the service, run SELECT * FROM TABLE(mydb.myschema.my_test_job!SPCS_GET_LOGS());

   Why: This shows that log access can be limited to one service without opening the whole event table.

   You should see: Rows with TIMESTAMP, INSTANCE_ID, CONTAINER_NAME, LOG and RECORD_ATTRIBUTES for the past day.

3. 3.As a role with full event table access, run the event-table query filtered on RESOURCE_ATTRIBUTES:"snow.service.name" and RECORD_TYPE = 'LOG'.

   Why: A direct query reaches historical logs and every resource attribute, but it requires broad access.

   You should see: Up to 10 log rows from the last hour, newest first.