# Teams

Every member of an organization is required to be part of a team. Our ability to provide granular controls within every aspect of an organization comes from our ability to customize team actions. This is accomplished by requiring all teams to have a policy. A policy is what gives teams permissions to take actions against all resources in an organization. All organizations created, by default, have three teams: owner, admin, and member.

# seekrit teams:create

Creates a team within an organization

USAGE
  $ seekrit teams:create [TEAM]

ARGUMENTS
  TEAM  Name of new team.

OPTIONS
  -o, --organization=organization  Name of organization to create a team under.
  -p, --path=path                  Path of policy to apply on newly created team.

# seekrit teams:list

Lists all teams in an organization.

USAGE
  $ seekrit teams:list

OPTIONS
  -o, --organization=organization  Name of organization to see all Teams under.

# seekrit teams:delete

Delete a team from an organization.

USAGE
  $ seekrit teams:delete [TEAM]

ARGUMENTS
  TEAM  Name of team to be deleted under an organization.

OPTIONS
  -o, --organization=organization  Name of organization.

# Team Members

Manage members of a team.

# seekrit teams:members:invite

Invite a new member to a team.

USAGE
  $ seekrit teams:members:invite [EMAIL]

ARGUMENTS
  EMAIL  Email of member to add to team.

OPTIONS
  -o, --organization=organization  Name of organization.
  -t, --team=team                  Name of team.

# seekrit teams:members:list

Lists all members under a team.

USAGE
  $ seekrit teams:members:list [TEAM]

ARGUMENTS
  TEAM  Team name to view members under.

OPTIONS
  -o, --organization=organization  Name of organization to see all Teams under.

# seekrit teams:members:remove

Remove a member from a team.

USAGE
  $ seekrit teams:members:remove [EMAIL]

ARGUMENTS
  EMAIL  Email of member to remove from team.

OPTIONS
  -o, --organization=organization  Name of organization.
  -t, --team=team                  Name of team.

# Team Policy

A policy is what gives teams permissions to take actions against all resources in an organization. We give you the ability to manage all policies associated to a team because we understand that teams roles are constantly changing.

# seekrit teams:policy:update

Overwrites the policy associated with a team.

USAGE
  $ seekrit teams:policy:update [PATH]

ARGUMENTS
  PATH  Path of policy.

OPTIONS
  -o, --organization=organization  Name of Organization to create a team under.
  -t, --team=team                  Name of Team to overwrite a policy for.

# seekrit teams:policy:view

Fetches a team's policy.

USAGE
  $ seekrit teams:policy:view [TEAM]

ARGUMENTS
  TEAM  Name of team to fetch a associated policy from.

OPTIONS
  -o, --organization=organization  Name of organization.

# Policy Structure

All policies are declared in YAML format. You set permissions by specifying a path along with allow and/or deny actions.

version: '1.0' # version required, to protect against any future policy format changes.

permissions:
- path:
  allow:
  deny:

- path:
  allow:
  deny:

The path is mandatory and at least one of allow or deny must be specified.

The path in policies specify the resources in your organization. You can think of a path as /${org}/projects/environments/secrets. When you create your own policy you will have to replace ${org} with the ACTUAL name of your organization. For example if I have an organization named myorg, a path to place restrictions on all projects will look like:

- path: /myorg/*
  allow: ['read', 'delete']
  deny: ['delete']

A path can also be used to specify restrictions on teams. Paths that refer to teams MUST begin with teams:.

- path: teams:*
  allow: ['read', 'delete']

- path: teams:owner
  deny: ['delete']

- path: teams:[developers|sales]
  allow: ['create', 'read', 'delete', 'update']

allow and deny can contain 1 or more of the following actions: create, read, delete, and/or update. If the allow and deny fields both contain the same action, the deny will supersede the allow actions.

# Owner policy

Owners have full access to every action possible in the organization.

version: '1.0'

permissions:
- path: teams:*
  allow: ['create', 'read', 'update', 'delete']

- path: /${org}
  allow: ['read', 'update', 'delete']

- path: /${org}/*
  allow: ['create', 'read', 'update', 'delete']

- path: /${org}/*/*
  allow: ['create', 'read', 'update', 'delete']

- path: /${org}/*/*/*
  allow: ['create', 'read', 'update', 'delete']

# Admin policy

Admins, similarly, have full access to every action except two: delete the organization and managing the owner team.

version: '1.0'

permissions:
- path: teams:owner
  deny: ['create', 'read', 'update', 'delete']

- path: teams:*
  allow: ['create', 'read', 'update', 'delete']

- path: /${org}
  allow: ['read', 'update']

- path: /${org}/*
  allow: ['create', 'read', 'update', 'delete']

- path: /${org}/*/*
  allow: ['create', 'read', 'update', 'delete']

- path: /${org}/*/*/*
  allow: ['create', 'read', 'update', 'delete']

# Member policy

Members have limited actions. Their role is primarily used for creating projects, envs and secrets. This role is suited for developers who do not need any management permissions.

version: '1.0'

permissions:
- path: /${org}/*
  allow: ['create', 'read']

- path: /${org}/*/*
  allow: ['create', 'read']

- path: /${org}/*/*/*
  allow: ['create', 'read', 'update', 'delete']

# Creating Policies by Example

Here we will list examples of how you can structure your policy to achieve the granularity your organization requires.

Allow all actions to development and staging secrets, but read-only to production secrets.

version: '1.0'

permissions:
- path: /${org}/*/[development|staging]/*
  allow: ['create', 'read', 'update', 'delete']

- path: /${org}/*/production/*
  allow: ['read']

Deny users from being able to delete specific projects and environments.

version: '1.0'

permissions:
- path: /${org}/*/*
  allow: ['create', 'read', 'update', 'delete']

- path: /${org}/[play|fiesta]
  allow: ['create', 'read', 'update']
  deny: ['delete']

- path: /${org}/*/production
  deny: ['delete']

Allows all actions to any team that begins with dev.

version: '1.0'

permissions:
- path: teams:dev*
  allow: ['create', 'read', 'update', 'delete']

By now you may be wondering how exactly does the path syntax work? It is loosely based on glob patterns with some custom logic. Please refer to examples below: