Skip to main content
Version: Beta 🚧

User Management and Access Controls

Access control concepts

info

Tecton Access Controls govern access to Tecton metadata and online features, but not access to offline data. See limitations.

In Tecton, access controls are used to specify what actions a principal is able to perform, where a principal is a user, Service Account, or principal group. A Service Account is used whenever you need an API key to access to Tecton, such as CI/CD systems or applications accessing features.

Role-based access control

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.

Principal groups

Public Preview

This feature is currently in Public Preview.

Users and Service Accounts can be added to Principal Groups. Once a member of a Principal Group, the User or Service Account will inherit any roles granted to the Group.

Summary of roles and permissions

Workspace-level roles

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.

Instance-level roles

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 live workspaces.

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.

All-Workspace roles

Any of the workspace-level roles can optionally be granted across all workspaces, to a user or a Service Account. Doing so allows the user or Service Account to perform the actions allowed by that role, across all workspaces. The principal will automatically assume that role on all new workspaces created thereafter.

Only admins can assign an all-workspace role to a user or Service Account.

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.

TaskHow to perform the task
Add a user to the workspaceUnder the User's tab, click Add User to workspace.
Remove a user from the workspaceFor 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 rolesFor 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 workspaceSelect the Service Accounts tab, then click Add Service Account to workspace.
Remove a Service Account from the workspaceFor 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 rolesFor 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

info

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.

User management

TaskHow 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.

Service Account management

TaskHow to perform the task
Create a Service Account.Select the Service Accounts tab, and click Create new Service Account.
Deactivate and delete a Service AccountIn the Actions column, click Deactivate. Once deactivated, click Delete in the Actions column.

Principal Group management

TaskHow to perform the task
Create a Principal GroupOn the Groups tab, click Create Group. Enter a unique name and optionally a description.
Add Users or Service Accounts to a Principal GroupOn the Groups tab, click on the group's name. On the right side, in the Users or Service Accounts tab, click Add User or Service Account to Group and select the members.
Remove Users or Service Accounts from a Principal GroupOn the Groups tab, click on the group's name. On the right side, in the Users or Service Accounts tab, click the delete icon next to the principals to delete.
Modify IdP attributes for a Principal GroupOn the Groups tab, click on the group's name. On the left side, in the Identity Provider Attributes section, click Add Attribute, or click the update or delete icons next to an existing attribute.

Assigning and un-assigning access

TaskHow to perform the task
Show all workspaces a principal has access to, along with the roles they have been granted in each workspace.On the Users, Service Accounts, or Groups tab, click on the principal’s name. This information is shown on the right side.
Add a principal to a workspace.On the Users, Service Accounts, or Groups tab, click on the principal’s name. At the top, click Assign Workspace Access.
Modify a principal’s workspace roles.On the Users, Service Accounts, or Groups 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, Service Accounts, or Groups 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 and role assignments with the CLI

The Tecton CLI additionally provides commands for creating and managing Service Accounts, and assigning or unassigning roles.

Service Account Management

To create, modify, and delete Service Accounts, use the tecton service-account command. Run tecton service-account --help for details on how to use the command.

Assigning and un-assigning access

To list, assign, or unassign a role from a principal, use the tecton access-control command. Run tecton access-control --help for details on how to use the command.

Authentication introspection

For convenience, you can also run the tecton whoami CLI command to inspect what principal is being used to authenticate the CLI.

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.

Group management using an identity provider

Public Preview

This feature is currently in Public Preview.

Group membership in Tecton can be configured through an Identity Provider attribute. Please configure your Identity Provider to send group membership information via an attribute named groups.

Then have your Tecton administrator create a principal group and set the list of IdP attributes for that group.

On the next user login, if the SAML assertion contains any of those attributes, the user will be added to that group. If the user was previously manually added to that group, the membership will then become IdP managed. This means if the attribute(s) is ever removed for the user, then they will automatically be removed from the group on their next login.

For example, consider two principal groups with these IdP attributes:

  • Group A: attributes product-team, product,
  • Group B: attributes engineering

This is how different groups attributes will map a user to group memberships:

  • Alice (groups: engineering) will get added to Group B
  • Bob (groups: engineering, product) will get added to Groups A and B
  • Carl (groups: other-team) will get added to neither Group A nor B

Suppose on Bob's next login the groups attribute changes. His group memberships will be updated:

  • Bob (groups: product) will be removed from Group B but remain in Group A

Best practices for configuring access controls

Use Principal Groups for managing access

Create principal groups with different access levels. For example, create an admin group for your Tecton administrators, and then grant it the admin role. Or create a group for a team of users with access granted on a set of workspaces. Grant the group a role on a new workspace, and all users in the group will inherit this role on the new workspace.

The moment a member is removed from the group, they immediately lose access to the roles and permissions they inherited from the group membership. They may still have access to the workspace via a role directly assigned to them.

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.

Use the tecton.set_credentials() 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.

Limitations

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

Workspace permissions

These roles are configured per workspace, or across all workspaces.

PermissionOwner roleEditor roleConsumer roleOperator roleViewer role
View workspace objects (such as data sources and feature views) and health status of the workspacexxxxx
Interact with workspace objects in SDKxxxxx
Request online features*xxx
Delete workspacex
Run tecton planxxxxx
Run tecton applyxx
Run tecton apply --suppress-recreatesx
Run tecton restorexxxxx
Create and delete datasetsxx
FeatureTable.ingest()xx
FeatureView.delete_keys()xx
Cancel/retry/overwrite materialization jobsxxx
Manually trigger materialization jobsxxx

* Role changes may take up to a minute to propagate to the GetFeatures API.

Platform management permissions

PermissionAdmin rolePrincipal role
Create live workspacex
Create dev workspacexx
Invite users (create, delete, resend)x
View all usersxx
Remove user from accountx
Create a Service Accountxx
Modify Service Account metadataxx*
Deactivate or Delete a Service Accountxx*
Create or update a Principal Groupx
Delete a Principal Groupx
Edit IdP attributes for a Principal Groupx
View IdP attributes for a Principal Groupx
Add members to a Principal Groupx
Modify Data Platform configurationx

* Only if the principal created the Service Account.

Access control permissions

PermissionAdmin rolePrincipal roleOwner roleEditor roleConsumer roleOperator roleViewer role
View your assignments for user-facing rolesxx
View account typesx
Modify account typesx
Assign/unassign All Workspaces rolex
View assignments of workspace-level rolesxx*x*x*x*x*
Assign/unassign workspace-level rolesxx*

* The role applies to a specific workspace, or across all workspaces.

Was this page helpful?

Happy React is loading...

🧠 Hi! Ask me anything about Tecton!

Floating button icon