Each Service belongs to a single Namespace. Namespaces are a way of grouping a collection of Services according to a common functionality (e.g. project names, environments such as production or staging, regions, etc...) and you are free to create as many Namespaces as you want. A Namespace also affects the domain name of Services as it acts as the parent domain for Services belonging to it (read more about Service DNS here). By default, if you do not explicitly specify a Namespace, the Service will automatically belong to the default Namespace which is created automatically upon the Cluster's installation. Here is an example for a Service that belongs to the default Namespace:

1
kind: Service
2
metadata:
3
  name: webapp
4
spec:
5
  mode: WEB
6
  config:
7
    upstream:
8
      url: http://nginx.local

Creating a Namespace

You can create a Namespace as follows:

1
kind: Namespace
2
metadata:
3
  name: production
4
spec: {}

Here is an example of a Service with the same name (i.e. webapp) but belongs to the Namespace production we just created:

1
kind: Service
2
metadata:
3
  name: webapp.production
4
spec:
5
  mode: WEB
6
  config:
7
    upstream:
8
      url: http://nginx.local

Policies

Policies (read more about Policies and access control here) can be created and/or attached to Namespaces where they can act as resource-based policies for all the Services belonging to a certain Namespace. Here is an example:

1
kind: Namespace
2
metadata:
3
  name: production
4
spec:
5
  authorization:
6
    policies: ["policy-1", "policy-2"]
7
    inlinePolicies:
8
      - spec:
9
          rules:
10
            - effect: ALLOW
11
              condition:
12
                match: '"group-1" in ctx.user.spec.groups'

Attributes

You can extend the information of a Namespace by feeding it additional information manually or dynamically via the APIs (read more here) 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). Here is an example:

1
kind: Namespace
2
metadata:
3
  name: production
4
spec:
5
  attrs:
6
    isProduction: true
7
    priority: 1000
8
    someKey:
9
      key1: val1
10
      key2: 100
11
      key3: true
12
      key4:
13
        subKey1: subVal1