Teams and access control

When more than one person works in dagweave, a team is how you share workflows and control who can do what. Teams and the access controls on this page are part of a paid plan.

Teams and roles

A team owns workflows and is the unit dagweave bills. Every account starts with its own personal team, and you invite people into a shared team to work together.

Each member has a role, and the roles stack from least to most access:

• Viewer can read.
• Editor can read, create, edit, and run workflows.
• Admin can do everything an editor can, plus delete workflows and manage members.
• Owner can do everything an admin can, plus manage billing, and every team keeps at least one.

An admin or owner invites people by email and picks the role they join with. The invite link stays valid for seven days. You can change a member’s role later, and the last owner cannot be removed.

Buying a plan and changing one later is covered in Plans and billing.

Fine-grained access

Roles set what a member can do across the whole team. When you need to be more precise, dagweave supports two finer controls:

• Per-object sharing. Give one teammate view or edit access to a single workflow, connector or template, without changing their team role. Those three types and those two levels are the whole surface. Running comes with editing and cannot be granted on its own. A repository cannot be shared this way at all. A grant names a person or a group, and whoever it reaches has to already be in the team that owns the resource.
• Relationship-based access control. Access follows the relationships between users, teams and objects rather than a flat role. A grant applies to the object it names and nothing else. A workflow inherits nothing from its folder. A folder is a text label, not an object you can share.

A per-object grant is not written to the audit log below, so the share list on an object is the only record of who has been given access to it.

A second factor

Sign-in takes a password and then either a one-time code from an authenticator app or a passkey, where the device unlock is the second factor. Nobody is forced onto it: each person turns it on for their own account, under Security.

Single sign-on with Google

Sign your team in through Google Workspace instead of passwords. An owner or admin sets it up under Team settings, Sign-in.

Type your Workspace domain and save it, then click Test with Google and sign in with an account on that domain. dagweave accepts the proof only if the account’s domain matches the one you typed, which is what stops a typo locking your company out of its own account.

Once the domain is proved you can tick Require Google sign-in for this team. From then on your people sign in with Google and nothing else: passwords and GitHub are refused. Their passwords are not deleted, so turning the requirement back off gives them their old way in.

Signing in starts with an email address. If it is on a domain that requires Google, dagweave sends the person to Google rather than asking for a password.

Groups

Grant a group rather than one person at a time. The data team gets the pipeline, instead of five people getting it one by one. Someone joining the group picks up what the group holds, and loses it on the way out.

You build groups in dagweave and put people in them, or map a Google group to a dagweave group and let your directory decide.

Groups from your directory

Somebody added to the Google group joins the dagweave group and the team, and somebody removed loses both. dagweave rechecks every fifteen minutes, so a removal in Google takes effect within that rather than at their next sign-in.

Owners are the exception. A sync never removes or demotes an owner, so whoever set this up cannot be locked out by their own directory.

Reading your groups needs your Workspace super admin to authorise dagweave for read-only directory access, under Security, Access and data control, API controls, Manage Domain-Wide Delegation. Without it, sign-in still works and group mapping does not.

Cluster access

Seeing a workflow in dagweave is one thing. What it can touch once it reaches your cluster is another. Scope a group to the namespaces it may dispatch to, and to the service account its workflows run as, without writing a Role or a RoleBinding by hand.

That service account can be ephemeral. It is built for the one run and owned by it, so Kubernetes takes it away with the workflow object rather than leaving a standing credential on the cluster.

What it may ask for is decided by whoever installed the connector. They write the list of permissions dagweave is allowed to offer, and nothing outside that list can be granted or even picked. It is off until they turn it on. Run identity covers the setup and what enabling it costs a cluster.

A run can also get its own namespace. Deleting it takes the pods, the volumes and anything else the workflow made. Either way the Argo Workflows controller has to watch the namespace. A cluster-scoped install covers both cases on its own. A namespace-scoped install watches one namespace. There, a group namespace means pointing a controller at it, and a per-run namespace cannot work at all. The name does not exist until the run starts.

An approval step can sit in front of all of it, so nothing reaches the cluster until whoever owns it says so.

Multi-factor sign-in

Accounts can add a second factor at sign-in:

• An authenticator app using a time-based one-time code (TOTP).
• Passkeys using WebAuthn, and you can register more than one.

When you enrol, dagweave gives you ten single-use recovery codes to get back in if you lose your factor. An account counts as protected once it has at least one confirmed factor.

Audit log

Every team has an append-only audit log. It records who did what: sign-ins and sign-outs, multi-factor changes, workflow create, edit, delete, publish, and run, API token minting and revoking, team and member changes, and billing changes. Entries cannot be edited or deleted.

You can filter the log by action, by actor, by outcome, and by a time window, and export the results as CSV. The CSV carries the timestamp, actor email and IP, action, object, and outcome. It leaves out the free-form details an event may also hold, so anything recorded there does not survive the export.