# Groups

> Octelium documentation. Canonical page: <https://octelium.com/docs/octelium/latest/management/core/group>.

A *User* may belong to one or more *Groups*. A *Group* is simply a way to collect *Users* according to whatever classification needed by the *Cluster* administrators (e.g. roles in a company such as DevOps or developers, different groupings of workloads, etc...). *Groups* can be especially useful for access control where you can apply *Policies* to a whole set of *Users* instead of trying to enforce them upon each one. Here is an example:

```yaml
kind: Group
metadata:
  name: dev
spec: {}
```

And you can attach a *Group* to a *User* simply as follows:

```yaml
kind: User
metadata:
  name: john
spec:
# !mark
  groups: ["dev"]
```

You can obviously attach as many *Groups* as you wish to a certain *User*. Here is an example:

```yaml
kind: User
metadata:
  name: john
spec:
  groups: ["dev", "ops", "management"]
```

## Listing Groups

You can list the *Cluster*'s *Groups* (read more about listing resources [here](https://octelium.com/docs/octelium/latest/management/core/overview.md#listing-resources)) as follows:

```bash
octeliumctl get group
# Or simply
octeliumctl get grp

# Show a certain Group
octeliumctl get grp devops


# Delete a Group
octeliumctl delete group dev
# Or simply
octeliumctl del grp dev
```

## Policies

*Policies* (read more about *Policies* and access control [here](https://octelium.com/docs/octelium/latest/management/core/policy.md)) can be created and/or attached to *Groups* where they can act as principal-based policies for all the *Users* belonging to a certain *Group*. Here is an example:

```yaml
kind: Group
metadata:
  name: dev
spec:
  authorization:
    policies: ["policy-1", "policy-2"]
    inlinePolicies:
      - spec:
          rules:
            - effect: DENY
              condition:
                match: ctx.service.status.namespaceRef.name == "production"
```

## Attributes

You can extend the information of a *Group* by feeding it additional information manually or dynamically via the APIs (read more [here](https://octelium.com/docs/octelium/latest/management/guide/sdk.md)) from external sources (e.g. IAM platforms, SIEM tools, threat intelligence tools, incident alerting and on-call management tools, etc...). Such additional information can be especially useful for extending access control and making it as fine-grained and dynamic as you wish (read more [here](https://octelium.com/docs/octelium/latest/management/core/policy.md#extending-access-control)). Here is an example:

```yaml
kind: Group
metadata:
  name: admins
spec:
  attrs:
    isPrivileged: true
    priority: 1000
    googleWorkspace:
      isAdmin: true
    someKey:
      key1: val1
      key2: 100
      key3: true
      key4:
        subKey1: subVal1
```

> **Note:**
>
> The `attrs` field is also available for *Users*, *Services* and *Namespaces*.

## API Reference

[Group JSON Schema (Octelium core/v1, latest documentation)](https://octelium.com/schemas/octelium/latest/core.v1.Group.schema.json)