Teams

Let more people run workflows, safely.

dagweave gives the rest of your team a way into the Argo Workflows you already run. Control who sees what, down to a single workflow, and what their workflows can touch once they reach your cluster.

The problem

Who gets in, and what they can do once they're in.

You want more of the team running workflows without handing out cluster access.

That means deciding who each person is and what they are allowed to run.

Shared work

One workspace the whole team shares

Workflows, templates, connectors and triggers belong to the team, not whoever built them.

Folders and labels keep a workspace organized as it grows.

scopetext

private      ->  just you
team         ->  everyone in the workspace
marketplace  ->  published for other teams to install

Roles

Open it up without opening everything

Building and running workflows is the job. Deleting things and managing members stays with whoever already owns the account.

rolestext

viewer  ->  read the canvas and the run history
editor  ->  build workflows and dispatch runs
admin   ->  editor, plus delete and manage members
owner   ->  admin, plus the account itself

Granular access

Give a group exactly what it needs

Roles cover the whole workspace. Groups and grants cover everything narrower than that: the data team on their pipelines, one contractor on one connector.

Make the groups you need in dagweave and put people in them.
Someone joins the group and gets what the group has. They leave and it goes with them.

who gets whattext

role   ->  what someone can do across the whole workspace
group  ->  the data team, the on-call rota, whoever you like
grant  ->  read or edit, to a person or a group, on one object

Cluster access

Set cluster permissions without writing RBAC

Seeing a workflow in dagweave is one thing. What it can touch once it lands on your cluster is another. Scope a group to the namespaces it needs, running as a service account you built in dagweave rather than one somebody hand-wrote.

Pick the namespaces a group can dispatch to. Anywhere else is refused.
Nobody has to write a Role or a RoleBinding.
Give a group its own namespace, or give every run its own. Either way dagweave cleans up after itself.
Put it through an approval step before it reaches the cluster, if you want one.
dagweave installs it through the connector you already enrolled.

what a group is allowedtext

namespaces       ->  where their workflows are allowed to run
service account  ->  what those workflows can touch once there
lifetime         ->  namespace and account, created and removed with the run
approval         ->  optional, before any of it reaches the cluster

Sign-in

Your directory decides who gets in

Your people sign in with the account they already have.
A Google group maps to a dagweave group, and membership follows it.
Turn it on and passwords stop working for your team.

sign-intext

domain       ->  the Workspace domain your team signs in from
groups       ->  which Google groups map to which teams
enforcement  ->  Google only, once the domain is proved

Sign-in

A second factor on any account that turns it on

Sign-in takes a one-time code or a passkey on top of the password, for anyone who has enrolled one.

Time-based codes from whichever authenticator app your team already uses.
Passkeys, so a laptop or phone unlock is the second factor.
Nobody is forced onto it; each person turns it on for their own account.

accesstext

sign-in         ->  password, then a code or a passkey if enrolled
team membership ->  which workspace they land in
role + grants   ->  what they can do once there

Accountability

A record of who did what

A production job starts failing. The audit log says who changed it, and when.

Every action is logged, whether it succeeded or was refused.
Export as CSV for a reviewer, or read the full detail through the API.

Give the whole team access.

dagweave is in early access. Leave an email and we will bring you on as we open it up.