Many workloads running as containers in Snowpark Container Services (SPCS) will want to connect to a Snowflake warehouse to interact with data stored in Snowflake. You can use any of the supported Snowflake clients from within the container. However, there are several prerequisites for setting up this access:
To simplify access, Snowpark Container Services provides a token to the container in the file /snowflake/session/token that can be used for authentication. This token has many benefits:
The Snowflake connection parameter host parameter is particularly important. Using host means that the connection will resolve to a private IP address and, thus, will not connect to a public endpoint on the internet. Further, the private endpoint is not controlled by network policies, which avoids having to open up large IP address ranges in a network policy to allow access from SPCS containers to Snowflake.
Using a token instead of a username/password in a client library such as Python is straightforward. The sample code below shows making a connection:
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',
database = os.getenv('SNOWFLAKE_DATABASE'),
schema = os.getenv('SNOWFLAKE_SCHEMA')
)
In addition to the token and host parameters discussed above, the connection uses the predefined variables SNOWFLAKE_ACCOUNT, SNOWFLAKE_DATABASE, and SNOWFLAKE_SCHEMA. The values default to the same account, database, and schema in which the container’s Snowpark Container Services image registry resides.
Currently, the connection will have the same role as the one that created the service, but this may change in the future.
In summary, using the Snowflake-provided token to authenticate a connection to Snowflake from an SPCS container makes configuration more straightforward and provides a more secure connection.