How to Attach Service Account in Runtime and Notebook workspace

Syntasa’s Service Account (SA) framework provides two primary attachment points for cloud identities: the Notebook Workspace and the Runtime Template. Understanding where to attach a Service Account is key to balancing ease of use for your team with strict security requirements.

This guide explains the differences between these two attachment points, how to configure them, and the best practices for managing group-level identities.

Runtime Service Account — The Shared Default

Attaching a Service Account to a Runtime Template is the most efficient way to manage credentials for a group or a specific type of infrastructure.

What It Is

A Runtime Service Account acts as a default cloud identity assigned to a specific compute configuration, such as an EMR cluster or a Dataproc template.

How to Attach

1. Navigate to Infrastructure > Runtime Templates.
2. Edit an existing template or create a new one.
3. Locate the Service Account dropdown.
4. Select the SA that represents the group or project authorized to use this infrastructure.
   
   

Best For

Runtime-level Service Accounts are best suited for:

• Production pipelines
• Shared team clusters
• Standardized access across multiple jobs and workspaces

Any job or workspace using this runtime automatically inherits these credentials.

Notebook Workspace Service Account — The Specific Override

Attaching a Service Account directly to a Notebook Workspace provides granular control for interactive data science and ad-hoc research.

What It Is

A Workspace Service Account is a specific cloud identity that applies only to the kernels launched within that particular workspace.

How to Attach

1. Navigate to Notebooks and open your Workspace configuration.
2. In the Configure tab, locate the Service Account field.
3. Select the SA you wish to use for your interactive session.
   
   

Best For

Workspace-level Service Accounts are ideal for:

• Sensitive projects
• Testing new permission sets
• Accessing specific cloud buckets or datasets outside the team’s default runtime permissions

The Resolution Chain: “Most Specific Wins”

When you launch a notebook or run a job, Syntasa follows a hierarchical Resolution Chain to determine which cloud identity should be injected into the compute node.

Resolution Order

1. Workspace Level (Highest Priority)
   If the Workspace has an SA attached, it is used first. This allows users to override the default runtime credentials for their specific interactive session.
2. Runtime Level
   If the Workspace is set to “Inherit” or has no SA attached, the system checks the Runtime Template.
3. System Fallback (Lowest Priority)
   If no SA is found at either level, the platform falls back to the default System Service Account and applies standard session policies.

Best Practices

For Administrators

Standardize via Runtimes

Create team-specific runtimes (for example, Marketing-EMR-Runtime) and attach the appropriate team Service Account. This simplifies workspace creation and ensures consistent credential usage across the organization.

Use “No Service Account” for Sandboxes

For general-purpose exploration or low-risk experimentation, leave the SA field empty so the platform uses its default restricted-access identity.

Audit Attachments Before Deletion

Before deleting a Service Account, verify its associations. Syntasa blocks deletion of an SA if it is currently attached to an active Runtime or Workspace.

For Data Scientists & Engineers

Verify Identity in the Notebook

You can confirm which cloud identity is active by running standard cloud commands within the notebook environment, such as:

• aws sts get-caller-identity
• gcloud auth list

Restart Kernels After Changes

If you change the Service Account attached to a Workspace, restart the notebook kernel so the updated credentials are applied correctly.

Respect Sharing Boundaries

Only Service Accounts shared with your group will appear in the dropdown. If an expected SA is unavailable, contact your administrator to review the sharing configuration.

Summary Comparison