# Resources > Octelium documentation. Canonical page: . ## Core Resources ### ClusterConfig *Cluster* configuration, or simply *ClusterConfig*, acts as the sole source of truth for all global configurations and settings of the *Cluster*. You can read more about managing *ClusterConfig* [here](https://octelium.com/docs/octelium/latest/management/core/cluster-config.md). [ClusterConfig JSON Schema (Octelium core/v1, latest documentation)](https://octelium.com/schemas/octelium/latest/core.v1.ClusterConfig.schema.json) ### Service Each protected resource is represented in the *Cluster* by a *Service*. A *Service* is implemented by an identity-aware proxy (IaP) called [*Vigil*](https://octelium.com/docs/octelium/latest/reference/components.md#vigil) abstracting all dynamic network-layer details of the protected resource behind it and is capable of providing access control and visibility the application-layer for various protocols including HTTP, SSH, PostgreSQL, MySQL, among others. A protected resource can be running in any private network (e.g. on prem, private cloud, your own laptop behind a NAT, etc...). A protected resource can also be a protected public resource such as SaaS APIs, databases and SSH servers. You can read in detail about *Service* management [here](https://octelium.com/docs/octelium/latest/management/core/service/overview.md). [Service JSON Schema (Octelium core/v1, latest documentation)](https://octelium.com/schemas/octelium/latest/core.v1.Service.schema.json) ### User An Octelium *User* denotes to the entity that interacts with the Octelium *Cluster* and access its *Services*. A *User* can be `HUMAN` (used by humans) or `WORKLOAD` (used by non-human entities such as containers, servers, programmable environments, etc...). In order for *Users* to be able to interact with an Octelium *Cluster*, they must first obtain a valid [*Session*](#session). During the installation of the Octelium *Cluster*, Octelium automatically creates a *User* called `root` with full permissions to control the *Cluster*. The *User* `root` or other *Users* created later having Administrator permissions can create more *Users*. A *User* may belong to one or more Octelium [*Groups*](https://octelium.com/docs/octelium/latest/reference/resources.md#group). A *User* can be managed both interactively using the `octeliumctl create user` and declaratively (which is the recommended way) using `octeliumctl apply`. Here is an example of a *User* resource. You can read the exact fields in the [User JSON Schema](https://octelium.com/schemas/octelium/latest/core.v1.User.schema.json). ```yaml kind: User metadata: name: user-1 spec: type: HUMAN email: john@example.com ``` [User JSON Schema (Octelium core/v1, latest documentation)](https://octelium.com/schemas/octelium/latest/core.v1.User.schema.json) ### Group A *User* may belong to one or more *Groups*. A *Group* is simply a way to collect *Users* in order to enforce rules and policies to a whole set of *Users* instead of applying them to each one (read more about [Policies and access control](https://octelium.com/docs/octelium/latest/management/core/policy.md)). A *Group* can be managed both interactively using the `octeliumctl create group` and declaratively (which is the recommended way) using `octeliumctl apply`. Here is an example of a *Group* resource. You can read the exact fields in the [Group JSON Schema](https://octelium.com/schemas/octelium/latest/core.v1.Group.schema.json). ```yaml kind: Group metadata: name: group-1 spec: {} ``` [Group JSON Schema (Octelium core/v1, latest documentation)](https://octelium.com/schemas/octelium/latest/core.v1.Group.schema.json) ### Session A *User* can interact with the Octelium *Cluster* and access its *Services* **only** through a valid *Session* that is automatically created upon a successfull authentication. Once the *Session* expires it gets automatically deleted by the *Cluster*. A *Session* can also be deleted manually either by the authenticated *User* using the `octelium logout`/ `octeliumctl logout` commands or by the *Cluster* administrators using the `octeliumctl delete session` command. [Session JSON Schema (Octelium core/v1, latest documentation)](https://octelium.com/schemas/octelium/latest/core.v1.Session.schema.json) ### Namespace An Octelium *Namespace* provides a mechanism for isolating groups of *Services* within the *Cluster* according to the needs of the *Cluster* administrators. A *Service* belongs to one *Namespace* and thus the name of the *Service* must be unique among all *Services* within a *Namespace*. There are no practical limits as to how many *Namespaces* that can be created. By default, the *Cluster* creates a default *Namespace* with the name `default` upon the *Cluster*'s installation, when you do not explicitly set a *Service* to a user-defined *Namespace*, the *Service* automatically belongs to the `default` *Namespace*. A *Namespace* can be managed both interactively using the `octeliumctl create namespace` and declaratively (which is the recommended way) using `octeliumctl apply`. Here is an example of a *Namespace* resource. You can read the exact fields in the [Namespace JSON Schema](https://octelium.com/schemas/octelium/latest/core.v1.Namespace.schema.json). ```yaml kind: Namespace metadata: name: ns1 spec: {} ``` [Namespace JSON Schema (Octelium core/v1, latest documentation)](https://octelium.com/schemas/octelium/latest/core.v1.Namespace.schema.json) ### Secret A *Secret* is very similar to Kubernetes secrets. A *Secret* is a type dedicated for storing sensitive data such as API tokens and passwords where they can be used and referenced by other *Cluster* resources by the *Secret*'s name in order to not store sensitive data along with other *Cluster* configurations which can stored in git repositories for example. You can read in detail about *Secret* management [here](https://octelium.com/docs/octelium/latest/management/core/secret.md). *Secrets* are used by various other *Cluster* resources such as *Services* for example to provide secretless access(read more [here](https://octelium.com/docs/octelium/latest/management/core/service/secretless.md)). [Secret JSON Schema (Octelium core/v1, latest documentation)](https://octelium.com/schemas/octelium/latest/core.v1.Secret.schema.json) ### Device A *Device* is a representation by the *Cluster* of a *User*'s machine. A *Device* can be optionally registered/enrolled by a logged-in *User* via the command `octelium auth device register` or simply `octelium auth dev register` (read more [here](https://octelium.com/docs/octelium/latest/user/cli/authentication.md#device-authentication)). However, it's up to access control to allow or deny a *User* based on their *Device* information. You can read more about *Device* management [here](https://octelium.com/docs/octelium/latest/management/core/device.md). [Device JSON Schema (Octelium core/v1, latest documentation)](https://octelium.com/schemas/octelium/latest/core.v1.Device.schema.json) ### Credential A *Credential* is simply a credential issued by the *Cluster* to a certain *User* in the form of a JWT-like token in order to be used later for authentication. A *Credential* can have one of the 3 types: authentication tokens, OAuth2 client credentials and access tokens. You can read in detail about *Credential* management [here](https://octelium.com/docs/octelium/latest/management/core/credential.md). [Credential JSON Schema (Octelium core/v1, latest documentation)](https://octelium.com/schemas/octelium/latest/core.v1.Credential.schema.json) ### Gateway Each Kubernetes node that is part of the data-plane of the *Cluster* acts as a *Gateway* and a host for the *Services* running on that Kubernetes data-plane node. A *Gateway* primarily maintains the WireGuard/QUIC tunnel interfaces via a component called the [*Gateway Agent*](https://octelium.com/docs/octelium/latest/reference/components.md#gateway-agent). [Gateway JSON Schema (Octelium core/v1, latest documentation)](https://octelium.com/schemas/octelium/latest/core.v1.Gateway.schema.json) ### IdentityProvider An *IdentityProvider* represents an identity provider (IdP) that is used by the *Cluster* to authenticate and re-authenticate the *Users* in order for them to obtain and keep a valid *Session* to be able to interact with the *Cluster* and access its *Services*. An *IdentityProvider* has one of the following types: `github`, `oidc`, `saml`, and `oidcIdentityToken`. Read more about managing *IdentityProviders* [here](https://octelium.com/docs/octelium/latest/management/core/identity-providers.md). [IdentityProvider JSON Schema (Octelium core/v1, latest documentation)](https://octelium.com/schemas/octelium/latest/core.v1.IdentityProvider.schema.json) ### Region A single Octelium *Cluster* is designed to run on top of a single Kubernetes cluster or be distributed over multiple Kubernetes clusters. Each Kubernetes cluster acts as a single *Region* of the *Cluster*. The initial Kubernetes cluster represents the `default` *Region* upon which *Services* are deployed by default. You, however, can explicitly specify which *Region* a *Service* should be deployed on for better latency or other reasons (read more [here](https://octelium.com/docs/octelium/latest/management/core/service/overview.md#region)). [Region JSON Schema (Octelium core/v1, latest documentation)](https://octelium.com/schemas/octelium/latest/core.v1.Region.schema.json)