Access Controls & Secrets (Private Preview)
Tecton Access Controls is currently available in private preview and not enabled by default. Contact Tecton support for more details.
Tecton protects data access across 3 main interfaces:
- Serving Access: ACLs define which Tecton users are allowed to fetch feature values for exploration, training, or serving
- Config Access: ACLs define which Tecton users are allowed to update the features managed by Tecton
- Raw Data Access: Protects Tecton's access to raw data sources (data warehouses, data lakes, streams, etc.) consumed by feature transformation pipelines
Access Controls are tied to a Tecton principal. A principal could be an individual user (Alice or Bob), a service (e.g. a microservice making API requests) or a group of users and services.
principals can be managed in Tecton's Web UI admin interface:
New users can be created directly in the Web UI. Alternatively, Tecton supports SSO integration via SAML. New services' API keys can be created using the Tecton CLI (e.g.
By default, every Tecton user has access to Tecton's Web UI, SDK and CLI. However, the workspaces they can interact with is defined by the access control lists defined on the individual workspaces.
Workspace-Centric Data Protection
Data Protection is configured on an individual workspace level. As described in more detail here, a workspace is an isolated environment used by teams or individuals to manage features.
Workspaces are configured with an independent feature configuration, access control lists and secrets. Similarly, materialized data is tied to a specific workspace and never shared between workspaces.
An example set of workspaces to support different teams and individuals:
A workspace's feature configuration defines raw data sources (see VirtualDataSources) that provide raw data for feature transformation pipelines. Tecton supports IAM-role protected (e.g. Kinesis, S3), password-protected (e.g. Snowflake) and private-key protected (e.g. Kafka) data sources.
Tecton allows you to manage secrets using the CLI or Web UI. Secrets can be global or scoped to a specific workspace (a workspace secret with the same name as a global secret always takes precedence):
Secrets can be referenced directly within a workspace's feature configuration. See the following sample VirtualDataSource that provides access to a Snowflake table:
from tecton import VirtualDataSource, SnowflakeDSConfig, Secret snowflake_url = Secret("SNOWFLAKE_URL").value snowflake_user = Secret("SNOWFLAKE_USER").value snowflake_password = Secret("SNOWFLAKE_PASSWORD").value transaction_snowflake_ds = SnowflakeDSConfig( url=snowflake_url, user=snowflake_user, password=snowflake_password, database="SF_DB", schema="SAMPLE_EVENTS", warehouse="COMPUTE_WH", table="TRANSACTION_EVENTS", role="TECTON_ROLE" ) transaction_snowflake_vds = VirtualDataSource( name="transaction_snowflake_vds", batch_ds_config=transaction_snowflake_ds, )
Using secrets, you're able to use the same feature configuration across different workspaces which point at different data sources. For instance, you could apply the same feature configuration to a "production" workspace as well as to a "staging" workspace. The respective secrets of the workspaces can configure the URL, user and password for separate production and staging data sources.
tecton apply will fail if you reference a secret that does not exist.
If you change the IAM role of a workspace, Tecton's compute jobs will assume that IAM role for all materialization jobs. As a result, you have to ensure that the IAM role has adequate IAM permissions to access all data sources that your workspace's feature transformation pipelines depend on.
Access Control Lists
Every workspace is associated with an Access Control List (ACL). The ACL defines serving and config access for individual users, services or groups
ACLs can be configured directly in the Web UI:
The following permissions can be granted to a principal:
- Read Data gives a principal the right to fetch feature values for training or serving purposes
- Update Config allows a principal to update the workspace's configuration using the tecton cli (e.g. run
- Read Config allows a principal to view a workspace's configuration. When this is enabled, the workspace will show up for the principal in the Web UI. Further, the user can run
tecton restoreto retrieve a workspace's full configuration, including feature transformations
- Admin allows a principal to delete a workspace and edit its secrets
The following shows a few sample multi-user and multi-team setups that are supported by Tecton's Access Controls:
Example Scenario: CI/CD-gated production rollout
A common setup for production deployments of Tecton allows only a CI/CD pipeline service to update a production workspace's configuration. Individual users work in a shared staging workspace, but only the CI/CD pipeline can apply to production.
Such a setup can be supported with the following ACLs:
Production Workspace ACL
Staging Workspace ACL
Example Scenario: Simple Test Setup
The most simple setup is to have just one workspace and the entire team is able to read data and make changes to the configuration:
Example Scenario: Fully Isolated Multi-Team Setup
Sometimes, you will have many teams working on sensitive features that nobody in the company is allowed to have access to.
Using the ACLs it's easy to have two workspaces, "Team A" and "Team B" that only members of the respective Teams can see and access:
Team A Workspace ACL
Example Scenario: Share Feature Config with another Team
Sometimes, a team may be comfortable sharing its feature transformation code with other teams. However, data access is strictly limited:
Team A Workspace ACL
Example Scenario: Share Feature Data with another Team
In other cases, a team wants to make its feature data accessible to another team, but wants to keep the feature transformation logic private. This is possible with the following ACL configuration, allowing members of Team B to access feature data of Team A:
Team A Workspace ACL
If a member of Team B wants to define a FeatureService in its workspace that depends on a feature in Team A's workspace, this can be accomplished using a cross-workspace reference in the feature configuration. Sample FeatureService in Team B's feature configuration:
import tecton from tecton import FeatureService from feature_repo import transaction_features # Cross workspace Feature Reference team_a_workspace = tecton.Workspace("Team_A") merchant_features = team_a_workspace.get_feature_package("merchant_features") feature_service = FeatureService( name='transaction_feature_service', description='Feature service for transaction model', features=[ merchant_features, # Remote Workspace features transaction_features # Local features ] )
With such a setup, you have to be aware that any member of Team A is by default able to break the FeatureService by modifying the merchant_features. Running
tecton apply will raise a warning and indicate to the user that there are feature dependencies in other workspaces. However, that warning can be ignored and overwritten.
It is possible to change Tecton's default behavior and not allow upstream workspaces to apply any configuration changes that would impact dependent downstream workspaces. Please talk to your support engineer to change this default behavior.