[Feature]: Security Trust Center Resource Enablement

[Richard-Barrett]

Use Cases or Problem Statement

We would like to be able to control the enablement of the security trust center withing Terraform using the Snowflake Provider. However, this functionality is not available at this time and is not available within the SDK. As such there is a need for it to be controlled based on the account layer and we need to be able to enable and/or disable it at will. We also want to have granular control over the scanners implemented and the schedule. It would also be nice to implement custom scanners with our own embedded SQL as an option so maybe calling a stored_procedure resource and/or a snowflake_function.

Category

category:resource

Object type(s)

No response

Proposal

A simple terraform resource that allows us to set up and configure security trust center per account with a specific set of roles and rules we can enable as well as the scanner resources.

resource "security_trust_center" {
    // REQUIRED FLAGS
    enabled = bool
    scanner_freqency = string
    scanner_schedule = string
    scanner_timezone = string
   
    // OPTIONAL FLAGS
    scanner_packages = []string
}

It would also be nice to set up a monitoring resource maybe for this or control a separate email notification within this area so we can send all of the security findings to a specified email, webhook, and/or integration within Snowflake.

### How much impact is this issue causing?

Low

### Additional Information

See about adding the following for interactions with enabling security trust center

- [ ] Create an interface, validations, calls, and specified operations for it within pkg/sdk as security_trust_center_*.go and 
- [ ] Create the require structs and basic function calls to get the current status of trust center as enabled or disabled
- [ ] Has a dependency on the type of account that is trying to enable the security trust center as either standard, enterprise, and/or business critical
- [ ] Create a resource to call the sdk and enable/disable security trust center in pkg/resources as security_trust_center.go
- [ ] Create an optional statement to allow the enablement of the scanner schedule within the security_trust_center_*.go files within the SDK.

### Would you like to implement a fix?

- [ ] Yeah, I'll take it 😎

[sfc-gh-jcieslak]

Hey @Richard-Barrett 👋
Are all of the requested functionality possible to run within the worksheet with SQL? Right now, we're only using SQL and the gosnowflake driver for our communication with Snowflake.
Currently, we are working on preparing resources for v1, so we have to put this aside for a while, but we are open to contributions if you would like to add it yourself (with our guidance and help of course). You can see our contribution guideline just in case.

[Richard-Barrett]

Hey @Richard-Barrett 👋 Are all of the requested functionality possible to run within the worksheet with SQL? Right now, we're only using SQL and the gosnowflake driver for our communication with Snowflake. Currently, we are working on preparing resources for v1, so we have to put this aside for a while, but we are open to contributions if you would like to add it yourself (with our guidance and help of course). You can see our contribution guideline just in case.

@sfc-gh-jcieslak I cannot directly enable Snowflake's Security Trust Center using a SQL query in a Snowflake SQL worksheet, as it is not a feature or object you can control via SQL commands. The Security Trust Center is a platform provided by Snowflake to showcase compliance certifications, audit reports, and security features, and it's accessible via a web interface, not through SQL.

[Richard-Barrett]

Furthermore, I don't think it's able to be set programmatically with Golang just using the gosnowflake driver. If we wanted to really control this, we would probably have to start expanding to using other Golang libraries to make http calls to the API endpoint that sets it up like net/http, which seems to go against the thought of just using the gosnowflake library.

[sfc-gh-jcieslak]

Hey,
Thanks for the quick response. You're right that a non-SQL interface would be something new for the provider and would require more work in other areas (like provider configuration) than just new resources to make it work. Also, some research on the usability of the API and potential discussions with other teams would be needed. I'll document this issue and categorize it with similar ones because I believe that's not the first case of a non-SQL feature that could be utilized by the provider. Unfortunately, that's not something we can pick up, even in the near future, as currently, we are focusing on tasks essential for V1 and have plans for some post-V1 work. That being said, It has to wait more than just a bit, but we'll get to it eventually.

[Richard-Barrett]

No worries, I was just asked to put our Trust Center into Terraform by my organization, and I was like it's impossible at the moment. So no worries.