Can my team use it?

While our platform currently operates on a per-user account model, we understand the critical need for collaborative environments in modern technical…

While our platform currently operates on a per-user account model, we understand the critical need for collaborative environments in modern technical teams. We are actively developing enhanced team functionalities and Single Sign-On (SSO) capabilities to streamline management and improve security for organizations. This article details the current state, upcoming features, and interim strategies for teams.

Current Account Model: Individual User Focus

As of our latest stable release (v2.12.5), every account on our platform is tied to a unique email address and is managed individually. This design prioritizes direct user control and simplified onboarding for single contributors.

Account Creation: Each user registers independently with their email.
Subscription Management: Subscriptions (e.g., 'Pro Tier', 'Enterprise Compute Unit Pack') are linked directly to the individual account. Billing is managed per user.
Resource Ownership: Resources created or managed (e.g., VM instances, database schemas, custom dashboards) are owned by the creating user's account.
Access Control: Sharing of resources currently relies on direct invitation methods or public access settings, rather than hierarchical team permissions.

This individual model, while straightforward for solo users, can present challenges for teams requiring shared access, centralized billing, and consolidated administrative oversight.

Roadmap for Team and SSO Features

We are actively developing a comprehensive suite of team and organizational features, with a target release for initial functionalities in Q3 2024 (v2.14). Our roadmap includes:

Organizational Accounts and Centralized Billing

The core of our team initiative is the introduction of a top-level "Organization" account. This will act as a container for multiple user accounts and shared resources.

Organization Administrator Role: A designated role with privileges to manage members, subscriptions, and global organization settings.
Shared Subscription Pools: Organizations can purchase a pool of licenses or compute units that members can draw from, simplifying billing. For example, an 'Enterprise Compute Unit Pack' purchased by the organization could be consumed by any team member.
Centralized Invoicing: All billing for an organization's members and shared resources will be consolidated into a single invoice.

Role-Based Access Control (RBAC)

Granular permissions within organizations will be managed through RBAC, allowing for precise control over resource access.

Predefined Roles: Initial roles will include 'Owner', 'Admin', 'Contributor', and 'Viewer'.
Custom Roles (Planned v2.15): Future iterations will allow organizations to define custom roles with specific permissions sets.
Resource Scoping: Permissions can be applied at the organization level, project level, or even to individual resources (e.g., 'read-only access to database instance DB-PROD-01').

Single Sign-On (SSO) Integration

SSO is a critical security and convenience feature for enterprises. We plan to support industry-standard protocols.

SAML 2.0 Support: Initial implementation will focus on SAML 2.0, supporting integrations with popular Identity Providers (IdPs) like Okta, Azure AD, and PingFederate.
OpenID Connect (OIDC) Support (Planned v2.15): Following SAML, we will expand to support OIDC for broader compatibility.
Just-In-Time (JIT) Provisioning: Users logging in via SSO who do not yet have an account on our platform can be automatically provisioned, streamlining onboarding.
SCIM Integration (Planned v2.16): System for Cross-domain Identity Management (SCIM) for automated user and group provisioning/de-provisioning.

Interim Strategies for Team Collaboration (Pre-SSO/Team Features)

While awaiting the full rollout of team features, organizations can adopt several strategies to manage collaboration and access control.

1. Shared Project Credentials (Limited Scope)

For specific projects or resources that multiple users need to manage, a dedicated "service account" or shared project credentials can be used. This involves:

Creating a new individual account (e.g., project-xyz-admin@yourcompany.com).
Subscribing this account to the necessary tiers.
Sharing its credentials (securely!) among authorized team members.

Caution: This method carries significant security risks due to shared credentials. It lacks auditability and individual accountability. Implement robust password policies (strong, unique, rotated regularly) and restrict its use to the absolute minimum necessary resources.

2. API Key Management for Automation

For programmatic access and automation scripts, individual users can generate API keys. These keys can then be used in CI/CD pipelines or scripts. It is critical to manage these keys with extreme care.

# Example: Generating an API key for a specific user
$ stackvora-cli auth generate-api-key --user-id U123456 --description "CI/CD Pipeline Access for Project Alpha" --permissions "resource:read,resource:write:project_alpha" --expiry 30d

# Example: Using an API key in a script
export STACKVORA_API_KEY="sk_live_XXXXXXXXXXXXXXXXXXXXXX"
stackvora-cli project create --name "New Project From CI" --region us-east-1

Best Practices:

Generate dedicated API keys for specific purposes (e.g., 'CI/CD pipeline for Project X').
Assign the principle of least privilege: grant only the necessary permissions.
Set expiration dates for API keys if supported.
Store API keys securely (e.g., in an encrypted vault like HashiCorp Vault, AWS Secrets Manager, or Kubernetes Secrets with appropriate RBAC). Do not hardcode them in repositories.
Rotate API keys regularly.

3. Manual Resource Sharing & Transfer

Our platform allows for transferring ownership of certain resources between individual accounts. This can be a labor-intensive process but ensures clear ownership.

# Example: Transferring ownership of a database instance
$ stackvora-cli db transfer-ownership --instance-id db-prod-001 --new-owner-email teamlead@yourcompany.com
Are you sure you want to transfer ownership of 'db-prod-001' to teamlead@yourcompany.com? This action is irreversible. (yes/no): yes
Ownership of 'db-prod-001' successfully transferred to teamlead@yourcompany.com.

Considerations:

Not all resource types may support direct transfer. Consult resource-specific documentation.
This process is manual and does not scale well for large numbers of resources or frequent team changes.

Contact Us for Early Access & Feedback

We are keen to engage with organizations interested in leveraging our upcoming team and SSO features. Early access programs for these functionalities will be made available to select partners to gather critical feedback and ensure the features meet real-world enterprise requirements.

If your team requires these capabilities, please reach out to our sales or support team with details about your organizational structure, your current Identity Provider (IdP) if applicable, and your specific use cases. This input is invaluable in prioritizing and refining our development efforts.

Common Pitfalls

Over-reliance on shared individual credentials: This is a major security risk. Avoid it for critical systems and ensure strong, unique passwords with regular rotation if absolutely necessary.
API Key mismanagement: Hardcoding API keys or granting overly broad permissions can lead to security breaches. Always use secrets management solutions and the principle of least privilege.
Lack of centralized visibility: Without organization-level features, tracking resource ownership and usage across multiple individual accounts can become complex. Maintain external documentation or spreadsheets to map users to resources.
Manual user provisioning/de-provisioning: As team members join or leave, remember to manually create or deactivate their individual accounts to maintain security and avoid unnecessary costs.