Syntasa Service Accounts (SA) are first-class entities that allow teams and groups to bring their own cloud credentials into the platform. Instead of relying on a single, broad “System Service Account,” groups can now use specific cloud identities (AWS IAM Roles, GCP Service Accounts, etc.) to govern data access for their Notebooks and Spark jobs.
By using Service Accounts, you ensure that your cloud data remains isolated and that permissions are enforced based on the specific group or workspace performing the work.
Key Benefits
- Identity Isolation: Different teams can use different cloud identities, ensuring Team A cannot access Team B’s data buckets.
- Least Privilege: Grant only the specific cloud permissions required for a particular project or runtime.
- Simplified Governance: Manage cloud credentials within the Syntasa UI, with full support for sharing, rotation, and auditing.
- Seamless Inheritance: Attach a Service Account once to a Runtime, and all jobs using that runtime automatically inherit the correct credentials.
Supported Cloud Identity Types
Syntasa supports four primary cloud identity types for Service Accounts:
| Cloud Identity Type | Description |
|---|---|
| AWS IAM Role | Uses a Role ARN. Supports optional assumer credentials and External IDs. |
| AWS IAM User | Uses a standard Access Key and Secret Key pair. |
| GCP Service Account | Uses a Service Account email and a JSON key file. |
| Azure Service Principal | Uses a Tenant ID, Client ID, and Client Secret. |
Managing Service Accounts
Creating a Service Account
Administrators or users with serviceaccount_create permissions can create SAs.
Steps
- Navigate to the Admin Center > Service Accounts.
Click Add New.
- Enter a Name and Description.
Select the options (e.g. IAM Role or User credentials) that varies based on Provider (AWS, GCP, or Azure).
This example is from AWS Env. Provide the required credential details (e.g., JSON key for GCP or Role ARN for AWS).
Provider - AWS Provider- GCP - Click Save.
Sharing and Permissions
Service Accounts follow the standard Syntasa sharing model:
- Private: Only the owner can see and use the SA.
- Group: Shared with a specific group (e.g., “Data Science Team”).
- Public: Available to all users in the platform.
You can assign three levels of access:
| Permission Level | Description |
|---|---|
| canView | User can see the SA and attach it to their resources. |
| canEdit | User can update the credentials or description. |
| canManage | User can share or delete the SA. |
Attaching Service Accounts
Once created, Service Accounts can be attached to two primary resources:
Notebook Workspaces
Attaching an SA to a workspace ensures that every kernel launched within that workspace uses the specified cloud identity.
- How to attach: Open the Workspace configuration and select the desired SA from the Service Account dropdown.
- Effect: When you run code in your notebook, Spark and cloud SDKs (
boto3, GCS client) will automatically use the SA’s credentials.
Runtime Templates
Attaching an SA to a Runtime Template provides a “shared default” for all workloads using that infrastructure.
- How to attach: Open the Runtime Template configuration and select the SA.
- Effect: Any job or workspace that uses this runtime will inherit the SA’s credentials unless a more specific override is set.
The Resolution Chain: “Most Specific Wins”
Syntasa uses a hierarchical resolution chain to determine which cloud identity to use for a task:
- Workspace Level: If a Service Account is attached directly to the Notebook Workspace, it is used first.
- Runtime Level: If no Workspace SA is set, the system checks the attached Runtime Template.
- System Fallback: If no SA is found in the chain, the platform falls back to the default System Service Account.
Manual vs. Scheduled Mode
Service Accounts behave differently depending on how the work is triggered:
| Mode | Behavior |
|---|---|
| Manual Mode (Interactive) | Your User Identity governs what you can do in the Syntasa UI (RBAC), but the Service Account governs what data your code can touch in the cloud. |
| Scheduled Mode (Jobs) | The Service Account acts as the full principal. It uses its own assigned Syntasa roles to authorize the job execution and its cloud identity to access data. |
Security and Compliance
- Encryption at Rest: All sensitive credential fields (Secret Keys, JSON keys) are AES-encrypted before being stored in the database.
- Just-in-Time Delivery: Credentials are never stored in the job payload. They are fetched dynamically by the compute node over a secure TLS connection only when the task starts.
- Audit Logging: Every creation, update, rotation, or deletion of a Service Account is recorded in the Syntasa Audit Log, including the identity of the person who performed the action.