User Management and Access Controls
Access control concepts
In Tecton, access controls are used to specify what actions a principal is able to perform, where a principal is a user or Service Account. A Service Account is used whenever you need an API key to access to Tecton, such as CI/CD systems or applications accessing features.
Access controls are configured by granting roles to principals. Most roles apply to actions that a principal can perform in a specific workspace.
A role contains a set of permissions. A permission allows a principals to perform a specific action in Tecton.
Tecton Access Controls govern access to Tecton metadata and online features, but not access to offline data. See limitations.
Summary of roles and permissions
The following roles can be granted in a workspace.
- Owner: Can perform any action in an existing workspace. The Owner role is automatically granted to the creator of a workspace.
- Editor: Can modify the workspace itself, but not other users' access. Also includes Operator's and Consumer's permissions.
- Consumer: Can access online data. Also includes Viewer's permissions.
- Operator: Can manage materialization jobs. Also includes Viewer's permissions.
- Viewer: Can view definitions and metadata.
The Admin role
Principals with the
admin account type have the Admin role. The Admin role can
add/remove users, grant/revoke workspace-level roles to principals and create
The Principal role
Principals with the
default account type have the Principal role. This role
grants basic permissions, such as the permission to create development
workspaces and Service Accounts.
Configure Access Controls
Access controls can be configured on the Permissions screen and Accounts &
Access screen in your Tecton cluster’s Web UI, located at
https://<your Tecton instance prefix>.tecton.ai.
The Permissions screen contains a subset of the access control settings that are available on the Accounts & Access screen. See the next two sections for details.
The Permissions screen
The Permissions screen allows you to configure access controls for a specific workspace. To access this screen, select Permissions under the Workspaces section on the left side of the Web UI. After selecting Permissions, you will see a list of all users that have access to the workspace and the workspace roles each user has been granted. Selecting the Service Accounts tab will show you the same information for Service Accounts.
On the Permissions screen, you can perform the following tasks by following the steps specified in the second column.
|Task||How to perform the task|
|Add a user to the workspace||Under the User's tab, click Add User to workspace.|
|Remove a user from the workspace||For the user who you want to remove, click the Edit icon on the right, then select None and click Change access.|
|Modify a user’s workspace roles||For the user for whose workspace roles want to modify, click the Edit icon on the right, then select the appropriate role and click Change access.|
|Add a Service Account to the workspace||Select the Service Accounts tab, then click Add Service Account to workspace.|
|Remove a Service Account from the workspace||For the Service Account you want to remove, click the Edit icon on the right, then select None and click Change access.|
|Modify a Service Accounts’s workspace roles||For the Service Account for whose workspace roles want to modify, click the Edit icon on the right, then select the appropriate role and click Change access.|
The Accounts & Access screen
This screen is accessible only to users with the Admin role.
The Accounts & Access screen allows you to configure access controls for any workspace. Additionally, you can configure user access to your Tecton instance and create Service Accounts.
To access this screen, select Accounts & Access under the Workspaces section on the left side of the Web UI. After selecting Accounts & Access, you will see a list of all users who have access to your Tecton cluster. Selecting the Service Accounts tab will show you the same information for Service Accounts.
On this screen, you can perform the following tasks by following the steps specified in the second column.
|Task||How to perform the task|
|Add a user to the Tecton cluster.||Click Invite User.|
|Remove a user from the Tecton instance.||In the Actions column, click the Delete icon.|
|Unlock a user.||On the Users tab, click on the user’s name. On the left side, in the Admin Actions section, click Unlock User.|
|Create a Service Account.||Select the Service Accounts tab, and click Create new Service Account.|
|Deactivate and delete a Service Account||In the Actions column, click Deactivate. Once deactivated, click Delete in the Actions column.|
|Show all workspaces a principal has access to, along with the roles they have been granted in each workspace.||On the Users or Service Accounts tab, click on the principal’s name. This information is shown on the right side.|
|Add a principal to a workspace.||On the Users or Service Accounts tab, click on the principal’s name. At the top, click Assign Workspace Access.|
|Modify a principal’s workspace roles.||On the Users or Service Accounts tab, click on the principal’s name. On the right side, click the Edit icon on the right, then select None and click Change access.|
|Modify a principal’s account type.||On the Users or Service Accounts tab, click on the principal’s name. On the left side, click the Edit icon next to Account Type, and select the desired account type.|
Managing Service Accounts with the Tecton CLI
Service Accounts can additionally be created and deleted through the CLI. Run
tecton api-key -h to see the command options.
User management using an identity provider
If you use an identity provider with Tecton, Just-in-Time Provisioning occurs; the first time a user logs in to Tecton, a user account is created and the account appears on the Accounts & Access screen.
If a user is removed from your identity provider, the user account will still exist in Tecton. You will need to manually remove the user from the Accounts & Access screen.
Best practices for configuring access controls
Use caution when granting Owner or Editor role to live workspaces
A principal with Owner or Editor roles can take actions in a workspace that can
impact a production system. For example, running
tecton apply on a workspace
causes the workspace objects that were modified or removed to be deleted and
replaced with the objects that are being applied.
Typically the Editor role will only be granted to the Service Account used for CI/CD, as well as a limited number of team members in case there is a need to apply directly.
Users and service accounts who do not need to
tecton apply should be granted
either the Viewer role, to view the workspace and metadata, or the Operator
role, to also manage materialization jobs.
Use development workspaces for feature development
Feature development should be done in development workspaces. The developer should verify the transformation logic works as intended before promoting the feature to a production workspace.
Setting an API Key in a notebook
By default, the Tecton SDK will look for a Tecton API key in the secrets manager for your data platform. This default is suitable if you want uniform Notebook access for all users.
method to explicitly set the API key for your session. Retrieve this API key
from a secrets manager to avoid pasting it in plain text in your notebook.
Offline materialized feature access depends on AWS or Snowflake roles
Accessing offline materialized feature data with the Tecton SDK depends on both Tecton and underlying storage permissions. Accessing feature data without the Tecton SDK can be done with only permissions to the underlying feature storage.
The principal must have at least the Viewer role on the relevant workspace to
run commands that access offline materialized data, such as
FeatureService.get_historical_features(). To restrict a user's offline
materialized data access to specific workspaces, see
configuring offline store access per workspace.
For Tecton on Databricks or EMR, access to offline feature data depends on the instance profile for the notebook cluster having access to the Tecton S3 bucket created during deployment.
For Tecton on Snowflake, access to offline feature data depends on the user’s access to the Tecton database created during deployment.
Workspace objects, such as data sources and feature views, cannot be shared between workspaces
If you set up separate workspaces for different teams, they will not be able to share objects in these workspaces. You can however use the same object definitions in multiple workspaces.
Complete list of permissions for each role
These roles are configured per workspace.
|Permission||Owner role||Editor role||Consumer role||Operator role||Viewer role|
|View workspace objects (such as data sources and feature views) and health status of the workspace||x||x||x||x||x|
|Interact with workspace objects in SDK||x||x||x||x||x|
|Request online features*||x||x||x|
|Run tecton plan||x||x||x||x||x|
|Run tecton apply||x||x|
|Run tecton apply --suppress-recreates||x|
|Run tecton restore||x||x||x||x||x|
|Create and delete datasets||x||x|
|Cancel/retry/overwrite materialization jobs||x||x||x|
|Manually trigger materialization jobs||x||x||x|
* Role changes may take up to a minute to propagate to the GetFeatures API.
Platform management permissions
|Permission||Admin role||Principal role|
|Create live workspace||x|
|Create dev workspace||x||x|
|Invite users (create, delete, resend)||x|
|View all users||x||x|
|Remove user from account||x|
|Create a Service Account||x||x|
|Modify Service Account metadata||x||x*|
|Deactivate or Delete a Service Account||x||x*|
|Modify Data Platform configuration||x|
* Only if the principal created the Service Account.
Access control permissions
|Permission||Admin role||Principal role||Owner role||Editor role||Consumer role||Operator role||Viewer role|
|View your assignments for user-facing roles||x||x|
|View account types||x|
|Modify account types||x|
|Assign/unassign All Workspaces role||x|
|View assignments of workspace-level roles||x||x*||x*||x*||x*||x*|
|Assign/unassign workspace-level roles||x||x*|
* The role applies to a specific workspace.