Legacy Snowflake Integration

Legacy Snowflake Configuration (Deprecated)

Note: Panther no longer supports this method for new customers, and will be migrating existing customers towards one of the supported methods in the future.
This guide assumes you already have a Snowflake instance in AWS.
Ideally, your Panther deployment and Snowflake instance are in the same AWS region. Having both Panther and Snowflake in the same region lowers latency for queries and data movement (relative to cross region communications).
Panther uses two Snowflake users/roles to access your Snowflake instance:
    1.
    A read only user/role for queries
    2.
    An admin user/role with strict permissions only to the Panther databases to create tables when new log sources are onboarded into Panther.
There are 9 steps to configuring Panther integration with Snowflake.
    1.
    Security Team: Gather configuration information from Panther
    2.
    DBA: Gather configuration information from Snowflake
    3.
    DBA: Create the Panther databases in Snowflake
    4.
    DBA: Create a read only role and an administrative role in Snowflake (limited to Panther tables)
    5.
    DBA: Create a read only user and an administrative user in Snowflake
    6.
    DBA: Create a stored procedure to make creating AWS Secrets easier (optional)
    7.
    AWS Admin: Create a KMS key in your AWS account for Panther Snowflake Secrets
    8.
    AWS Admin: Create a read only user AWS Secret and an administrative user AWS Secret
    9.
    Panther (SaaS) or Customer (CloudPrem): Deploy Panther with Snowflake enabled

1. Gather configuration information from Panther

Go to the Settings page of Panther and select General Settings. There you will find:
    Snowflake ReadOnly Lambda Role ARN
    Snowflake Admin Lambda Role ARN
Keep these ARNs handy, we will use this later.

2. Gather configuration information from Snowflake

In order to configure Panther, you need to get the SNOWFLAKE_IAM_USER from Snowflake.
In a Snowflake SQL shell execute the below sql, replacing myaccountid with your AWS account ID and myaccountregion with the account's region:
1
SELECT system$get_aws_sns_iam_policy('arn:aws:sns:myaccountregion:myaccountid:panther-processed-data-notifications');
Copied!
You should see a response similar to:
1
{
2
"Version":"2012-10-17",
3
"Statement":[
4
{
5
"Sid":"1",
6
"Effect":"Allow",
7
"Principal":{
8
"AWS":"arn:aws:iam::87654321XXXX:user/k7m2-s-v2st0722"
9
},
10
"Action":["sns:Subscribe"],
11
"Resource":["arn:aws:sns:us-west-1:12345678XXXX:panther-processed-data-notifications"]
12
}
13
]
14
}
Copied!
In the above example, the SNOWFLAKE_IAM_USER is the AWS attribute arn:aws:iam::87654321XXXX:user/k7m2-s-v2st0722. Keep this handy, we will use this in a later step.

3. Create the Panther databases in Snowflake

Execute in Snowflake SQL shell:
1
USE ROLE SYSADMIN;
2
3
---------------- databases
4
CREATE database IF NOT EXISTS panther_logs;
5
CREATE database IF NOT EXISTS panther_rule_matches;
6
CREATE database IF NOT EXISTS panther_rule_errors;
7
CREATE database IF NOT EXISTS panther_cloudsecurity;
8
CREATE database IF NOT EXISTS panther_monitor;
9
CREATE database IF NOT EXISTS panther_views;
10
CREATE database IF NOT EXISTS panther_stored_procedures;
Copied!

4. Create a read only role and an administrative role in Snowflake

For customers with self-hosted Snowflake deployments who are upgrading to 1.18
Self-hosted customers using Snowflake data cloud should have their Database Administrator add the following permission set, or update their automation scripts to reflect the latest version of the setup instructions:
1
USE ROLE SECURITYADMIN;
2
GRANT CREATE STAGE, CREATE PIPE ON ALL SCHEMAS IN DATABASE PANTHER_MONITOR
3
TO ROLE panther_admin_role;
Copied!
NOTE: be sure to update <your warehouse> in the first line of the SQL block below to the desired Snowflake warehouse name that you wish Panther to use.
We recommend you create a dedicated Panther warehouse (e.g., PANTHER_WH), so that you can easily track costs and resize capacity independently of other Snowflake resources.
Execute in Snowflake SQL shell:
1
SET WAREHOUSE_NAME = '<your_warehouse>';
2
USE ROLE SECURITYADMIN;
3
4
--------------- create panther_readonly_role
5
CREATE ROLE IF NOT EXISTS panther_readonly_role;
6
7
---------------- grants for panther_readonly_role
8
9
-- warehouse
10
GRANT USAGE
11
ON WAREHOUSE IDENTIFIER($WAREHOUSE_NAME)
12
TO ROLE panther_readonly_role;
13
14
-- panther_logs
15
GRANT USAGE
16
ON DATABASE panther_logs
17
TO ROLE panther_readonly_role;
18
GRANT USAGE
19
ON SCHEMA panther_logs.public
20
TO ROLE panther_readonly_role;
21
GRANT SELECT
22
ON ALL TABLES IN SCHEMA panther_logs.public
23
TO ROLE panther_readonly_role;
24
GRANT SELECT
25
ON ALL VIEWS IN SCHEMA panther_logs.public
26
TO ROLE panther_readonly_role;
27
GRANT SELECT
28
ON FUTURE TABLES IN SCHEMA panther_logs.public
29
TO ROLE panther_readonly_role;
30
GRANT SELECT
31
ON FUTURE VIEWS IN SCHEMA panther_logs.public
32
TO ROLE panther_readonly_role;
33
34
-- panther_rule_matches
35
GRANT USAGE
36
ON DATABASE panther_rule_matches
37
TO ROLE panther_readonly_role;
38
GRANT USAGE
39
ON SCHEMA panther_rule_matches.public
40
TO ROLE panther_readonly_role;
41
GRANT SELECT
42
ON ALL TABLES IN SCHEMA panther_rule_matches.public
43
TO ROLE panther_readonly_role;
44
GRANT SELECT
45
ON ALL VIEWS IN SCHEMA panther_rule_matches.public
46
TO ROLE panther_readonly_role;
47
GRANT SELECT
48
ON FUTURE TABLES IN SCHEMA panther_rule_matches.public
49
TO ROLE panther_readonly_role;
50
GRANT SELECT
51
ON FUTURE VIEWS IN SCHEMA panther_rule_matches.public
52
TO ROLE panther_readonly_role;
53
54
-- panther_rule_errors
55
GRANT USAGE
56
ON DATABASE panther_rule_errors
57
TO ROLE panther_readonly_role;
58
GRANT USAGE
59
ON SCHEMA panther_rule_errors.public
60
TO ROLE panther_readonly_role;
61
GRANT SELECT
62
ON ALL TABLES IN SCHEMA panther_rule_errors.public
63
TO ROLE panther_readonly_role;
64
GRANT SELECT
65
ON ALL VIEWS IN SCHEMA panther_rule_errors.public
66
TO ROLE panther_readonly_role;
67
GRANT SELECT
68
ON FUTURE TABLES IN SCHEMA panther_rule_errors.public
69
TO ROLE panther_readonly_role;
70
GRANT SELECT
71
ON FUTURE VIEWS IN SCHEMA panther_rule_errors.public
72
TO ROLE panther_readonly_role;
73
74
-- panther_cloudsecurity
75
GRANT USAGE
76
ON DATABASE panther_cloudsecurity
77
TO ROLE panther_readonly_role;
78
GRANT USAGE
79
ON SCHEMA panther_cloudsecurity.public
80
TO ROLE panther_readonly_role;
81
GRANT SELECT
82
ON ALL TABLES IN SCHEMA panther_cloudsecurity.public
83
TO ROLE panther_readonly_role;
84
GRANT SELECT
85
ON ALL VIEWS IN SCHEMA panther_cloudsecurity.public
86
TO ROLE panther_readonly_role;
87
GRANT SELECT
88
ON FUTURE TABLES IN SCHEMA panther_cloudsecurity.public
89
TO ROLE panther_readonly_role;
90
GRANT SELECT
91
ON FUTURE VIEWS IN SCHEMA panther_cloudsecurity.public
92
TO ROLE panther_readonly_role;
93
94
--panther_monitor
95
GRANT USAGE
96
ON DATABASE PANTHER_MONITOR
97
TO ROLE PANTHER_READONLY_ROLE;
98
GRANT USAGE
99
ON SCHEMA PANTHER_MONITOR.PUBLIC
100
TO ROLE PANTHER_READONLY_ROLE;
101
GRANT SELECT
102
ON ALL TABLES IN SCHEMA PANTHER_MONITOR.PUBLIC
103
TO ROLE panther_readonly_role;
104
GRANT SELECT
105
ON ALL VIEWS IN SCHEMA PANTHER_MONITOR.PUBLIC
106
TO ROLE panther_readonly_role;
107
GRANT SELECT
108
ON FUTURE TABLES IN SCHEMA PANTHER_MONITOR.PUBLIC
109
TO ROLE panther_readonly_role;
110
GRANT SELECT
111
ON FUTURE VIEWS IN SCHEMA PANTHER_MONITOR.PUBLIC
112
TO ROLE panther_readonly_role;
113
114
-- panther_views
115
GRANT USAGE
116
ON DATABASE panther_views
117
TO ROLE panther_readonly_role;
118
GRANT USAGE
119
ON SCHEMA panther_views.public
120
TO ROLE panther_readonly_role;
121
GRANT SELECT
122
ON ALL TABLES IN SCHEMA panther_views.public
123
TO ROLE panther_readonly_role;
124
GRANT SELECT
125
ON ALL VIEWS IN SCHEMA panther_views.public
126
TO ROLE panther_readonly_role;
127
GRANT SELECT
128
ON FUTURE TABLES IN SCHEMA panther_views.public
129
TO ROLE panther_readonly_role;
130
GRANT SELECT
131
ON FUTURE VIEWS IN SCHEMA panther_views.public
132
TO ROLE panther_readonly_role;
133
134
--------------- create panther_admin_role
135
CREATE ROLE IF NOT EXISTS panther_admin_role;
136
137
GRANT ROLE panther_readonly_role
138
TO ROLE panther_admin_role;
139
140
---------------- grants for panther_admin_role
141
142
-- panther_logs
143
GRANT CREATE TABLE, CREATE VIEW, CREATE STAGE, CREATE PIPE, MODIFY
144
ON ALL SCHEMAS IN DATABASE panther_logs
145
TO ROLE panther_admin_role;
146
147
-- panther_rule_matches
148
GRANT CREATE TABLE, CREATE VIEW, CREATE STAGE, CREATE PIPE, MODIFY
149
ON ALL SCHEMAS IN DATABASE panther_rule_matches
150
TO ROLE panther_admin_role;
151
152
-- panther_rule_errors
153
GRANT CREATE TABLE, CREATE VIEW, CREATE STAGE, CREATE PIPE, MODIFY
154
ON ALL SCHEMAS IN DATABASE panther_rule_errors
155
TO ROLE panther_admin_role;
156
157
-- panther_cloudsecurity
158
GRANT CREATE TABLE, CREATE VIEW, CREATE STAGE, CREATE PIPE, MODIFY
159
ON ALL SCHEMAS IN DATABASE panther_cloudsecurity
160
TO ROLE panther_admin_role;
161
162
-- panther_monitor
163
GRANT CREATE TABLE, CREATE VIEW, CREATE STAGE, CREATE PIPE, MODIFY
164
ON ALL SCHEMAS IN DATABASE PANTHER_MONITOR
165
TO ROLE panther_admin_role;
166
GRANT SELECT, INSERT, UPDATE
167
ON ALL TABLES IN SCHEMA PANTHER_MONITOR.PUBLIC
168
TO ROLE PANTHER_ADMIN_ROLE;
169
GRANT SELECT, INSERT, UPDATE
170
ON FUTURE TABLES IN SCHEMA PANTHER_MONITOR.PUBLIC
171
TO ROLE PANTHER_ADMIN_ROLE;
172
173
-- panther_views
174
GRANT CREATE VIEW, MODIFY
175
ON ALL SCHEMAS IN DATABASE panther_views
176
TO ROLE panther_admin_role;
177
178
-- panther_stored_procedures
179
GRANT USAGE ON DATABASE panther_stored_procedures
180
TO ROLE panther_admin_role;
181
182
GRANT CREATE PROCEDURE, CREATE FUNCTION, MODIFY, USAGE
183
ON ALL SCHEMAS IN DATABASE panther_stored_procedures
184
TO ROLE panther_admin_role;
185
186
-- this allows panther_admin_role to create a storage integration for Panther's s3 bucket
187
-- NOTE: this grant can be removed after Panther is initially successfully onboarded
188
USE ROLE ACCOUNTADMIN;
189
190
GRANT CREATE INTEGRATION ON ACCOUNT TO ROLE panther_admin_role;
191
192
-- allow access to snowflake's audit database for panther (optional)
193
GRANT IMPORTED PRIVILEGES ON DATABASE snowflake TO ROLE panther_readonly_role;
Copied!

5. Create a read only user and an administrative user in Snowflake

NOTE: set <your_readonly_password> and <your_admin_password> below. Execute in Snowflake SQL shell:
1
USE ROLE SECURITYADMIN;
2
3
-- panther_readonly user
4
CREATE USER IF NOT EXISTS panther_readonly password='<your_readonly_password>';
5
6
GRANT ROLE panther_readonly_role
7
TO USER panther_readonly;
8
9
ALTER USER panther_readonly
10
SET default_role = panther_readonly_role;
11
12
-- panther_admin user
13
CREATE USER IF NOT EXISTS panther_admin password='<your_admin_password>';
14
15
GRANT ROLE panther_admin_role
16
TO USER panther_admin;
17
18
ALTER USER panther_admin
19
SET default_role = panther_admin_role;
20
21
ALTER USER PANTHER_ADMIN
22
SET TIMEZONE = 'UTC';
Copied!

6. Create a stored procedure to make creating AWS Secrets easier (Optional)

Define this stored procedure that will create a JSON document you can use to cut-n-paste into AWS Secret Manger (saving typing). Execute in Snowflake SQL shell:
1
USE ROLE SYSADMIN;
2
3
CREATE or replace FUNCTION panther_stored_procedures.public.generate_secret(USN VARCHAR, PWD VARCHAR, WHS VARCHAR, HST VARCHAR)
4
RETURNS OBJECT
5
LANGUAGE SQL
6
STRICT
7
AS
8
$
9
SELECT object_construct('account', current_account(),
10
'user', USN ,
11
'password', PWD ,
12
'host',TRIM(REPLACE(HST,'https://'),'/'),
13
'port','443',
14
'warehouse',WHS) AS SECRET
15
$;
16
-- Customize the values here to match your password, a compute warehouse you will be using, and your hostname.
17
-- The hostname is usually "<something>.snowflakecomputing.com" from the URL used to log into your cluster.
18
-- SELECT panther_stored_procedures.public.generate_secret('panther_readonly','password123','COMPUTE_WH','<something>.snowflakecomputing.com');
Copied!

7. Create a KMS key in your AWS account for Panther Snowflake Secrets

You will use this key to encrypt the Snowflake secrets that we will store in your AWS account as part of Step 8.
    Log in to your AWS account
    (Optional) Go to the same region that your Snowflake account is in
    Go to KMS service
    Click on Create a key
    Pick Symmetric for the type and click Next
    Set the alias to panther-secret. Click Next. On the next page Click Next (accept defaults)
    Click on Add another AWS Account and enter the account id where Panther is installed.
    Click Next and then click Finish.

8. Create a read only user AWS Secret and an administrative user AWS Secret

You will use AWS Secrets Manager to store the Snowflake user password. It will be configured to only allow access from a single lambda function in the Panther account.
Repeat the process below, once for panther_readonly user and once for the panther_admin user.
    Access the AWS Secrets Manager via the console and select Store a New Secret button on the page.
    You will be presented with a page titled Store a new secret. Select Other type of secrets from the list of types. Specify the following key/value pairs:
Field
Description
account
The name of your Snowflake account. It can be found by executing SELECT CURRENT_ACCOUNT()
user
Snowflake user you created earlier, either panther_readonly or panther_admin
password
The Snowflake user password that you created in Step 1
host
This is usually <something>.snowflakecomputing.com from the URL used to log into your cluster. Remove https:// and any trailing / from the hostname.
port
Use 443 unless you have configured differently
warehouse
The name of your Snowflake active warehouse
You can enter the above by hand OR run the following command in a Snowflake SQL shell, typing in the appropriate values for the 4 specified parameters (account and port should autopopulate). Do this once for the panther_readonly user and once for the panther_admin:
1
SELECT panther_stored_procedures.public.generate_secret(<user>,<password>,<warehouse>,<host>);
Copied!
You can then copy-paste the result into each of the 2 secrets "plaintext" editor tab.
NOTE: Check to make sure that all 6 fields (account, host, password, port, user, warehouse) are filled out and have the correct values, otherwise the Panther lambdas may encounter issues connecting to snowflake.
    Select panther-secret from the dropdown under Select the encryption key.
    Click Next.
    You will be presented with a screen asking for the name and description of the secret. Fill these in and click Next.
    The next screen concerns autorotation, just click the Next button.
    Finally, you will be presented with an overview screen. Scroll to the bottom and click the Store button.

Update Permissions for the Secrets

We need to configure the permissions for the two Panther AWS secrets such that only the specific Panther lambdas have access to the Snowflake secret.
The Panther panther-snowflake-api will use the panther_readonly user for user queries while the panther-snowflake-admin-api will use the panther_admin user to create tables when new log sources are onboarded.
Go to the console and select each of the secrets you created above. On the overview screen click on the Edit Permissions button. Copy the below policy JSON, substituting the appropriate <lambda role>, either:
    panther-snowflake-api role collected in the first step
    panther-snowflake-admin-api role collected in the first step
For the value of <secret ARN> use the ARN of the secret you are updating.
1
{
2
"Version": "2012-10-17",
3
"Statement": [
4
{
5
"Effect": "Allow",
6
"Principal": {"AWS": "<lambda role>" },
7
"Action": "secretsmanager:GetSecretValue",
8
"Resource": "<secret ARN>"
9
}
10
]
11
}
Copied!
Then click the Save button.
Make a note of the arn for the secret. We will use this later.

9. Deploy Panther with Snowflake enabled

SaaS Legacy Deployment Users

Send to your Panther point of contact (POC):
    SNOWFLAKE_IAM_USER collected in the first step
    ARN for the panther_readonly user AWS Secret
    ARN for the panther_admin user AWS Secret
Your Panther POC will re-deploy Panther with these settings to enable Snowflake.

CloudPrem Users

Customers running Panther in their own accounts (we call that CloudPrem) need to first deploy the master template doing an initial setup of Panther. After deploying the master template configure the master stack parameters as below:
    update: SnowflakeAPISecretARN parameter as the ARN of the secret created above for the panther_readonly user.
    update: SnowflakeAdminAPISecretARN parameter as the ARN of the secret created above for the panther_admin user.
    update: SnowflakeDestinationClusterARNs parameter as the value of <SNOWFLAKE_IAM_USER> from initial step above.
Execute an update to the Cloudformation stack.

Validation of Snowpipe Processing

Once Panther is configured for Snowflake, you should have seven databases:
    panther_logs
    panther_rule_matches
    panther_rule_errors
    panther_cloudsecurity
    panther_views
    pather_stored_procedures
    panther_monitor
These are the same database names used in AWS Athena and queries should behave similarly.
Assuming you have data being regularly being processed, there should be data in the tables in a few minutes. This depends on your rate of log ingestion.
You can quickly test if the data ingestion is working by running a simple query:
1
SELECT count(1) AS c FROM panther_views.public.all_logs ;
Copied!
The configuration can be tested from the Data Explorer. Run some same queries over a table that you know has data (check via Snowflake console).

Rotating Secrets

To rotate secrets, create a NEW user and edit the secret replacing the old user and password with the new user and password. Wait one hour before deleting/disabling the old user in Snowflake.
Last modified 1mo ago
Copy link