Skip to main content

​
Access management

VegaLake combines human and machine identities with reusable roles and groups. Access is permission-based and remains explicit at organization, workspace, collection, and resource-instance boundaries.

​
Identity types

Service-principal API keys are credentials. Store them in an approved secret system, show them only when necessary, and rotate or delete them when their consumer changes.
  1. Identify the exact action and resource scope required.
  2. Reuse or create a role containing only those permissions.
  3. Use a group when multiple identities share the same responsibility.
  4. Assign the role to the group, user, or service principal.
  5. Verify access using the intended organization and workspace.
  6. Remove superseded direct grants.
This least-privilege approach is easier to audit than broad direct permission assignment.

​
Collection and instance permissions

Collection permission controls operations across a resource family, such as listing or creating connections. Instance permission targets one existing resource. A user may be able to view one cluster without being able to create clusters globally.

​
Invitations and membership

Organization invitations add users through an explicit accept or reject flow. Administrators can list, resend, or cancel active invitations through the customer-facing IAM surface. Membership alone does not guarantee product access; roles, groups, and scoped permissions still apply.

​
Troubleshooting access

When an action is hidden or rejected, confirm identity, organization, workspace, resource scope, and permission assignment—in that order. Avoid relying on an error message to reveal a protected resource.