greymatter.io Documentation | Greymatter Operator

The greymatter.io operator is a Kubernetes extension that makes launching a mesh on Kubernetes quick and easy. You can use the operator to do the following:

Install the entire greymatter.io mesh in a single step
Perform updates of core greymatter.io mesh services
Automatically network pods in a list of namespaces into a service mesh
Bootstrap mesh configurations from Deployments and StatefulSets
Customize bootstrap mesh configuration templates via CUE definitions

Definition

name(String) - mesh display name
install_namespace(String) - namespace where greymatter.io core services will be installed
watch_namespaces(Array[String]) - namespaces that greymatter.io will discover services from
zone(String) - zone label for organizing mesh configurations
images(Object) - A map of OCI image strings for greymatter.io coreservices. Introduced in version v0.3.2
image_pull_secrets(Array[String]) - A list of secrets containing credentials to pull OCI compliant images. Introduced in version v0.3.2.
user_tokens(Array[Object]) - additional user tokens applied to the greymatter.io JWT Security service

Permissions

The operator orchestrates deploying a mesh across multiple pods and namespaces. As a result it requires a fair number of Role-based access control (RBAC) permissions to be shared with its service account. These are required for installing greymatter.io core services and configuring mesh capabilities.

Resource	Permission
`apps.deployments`	list, get, create, update
`apps.statefulsets`	list, get, create, update
`core.pods`	list
`core.configmaps`	get, create, update
`core.secrets`	get, create, patch
`core.serviceaccounts`	get, create, update
`core.services`	get, create, update
`rbac.clusterroles`	get, create, update
`rbac.clusterrolebindings`	get, create, update
`networking.ingresses`	get, create, update
`admissionregistration.mutatingwebhookconfigurations`	get, patch
`admissionregistration.validatingwebhookconfigurations`	get, patch

GitOps

The operator continuously fetches its configuration from a target GitOps repository, and applies it to the environment on each update. It may be configured using either an SSH or HTTPS URL.

SSH

If you followed the getting started page on installing greymatter on Kubernetes, you likely configured a GitOps target with an SSH URL. During that process you set the repository URL, SSH private key path, branch, and (optionally) the SSH private key password like so, in your operator.yaml or greymatter-core/gm/outputs/operator.cue CUE:

args:
  - -repo
  - git@github.com:<your-org>/greymatter-core.git
  - -sshPrivateKeyPath
  - /app/.ssh/ssh-private-key
  - -branch
  - main
  # optional
  - -sshPrivateKeyPassword
  - YOUR_SSH_KEY_PASSWORD

HTTPS

To configure the operator to use an HTTPS GitOps target instead, you will specify only the URL and branch like so:

args:
  - -repo
  - https://gitlab.com/your-org/greymatter-core.git
  - -branch
  - main

and then you must provide your basic authentication credentials as environment variables. This is most securely accomplished using a Kubernetes Secret, referenced from your operator StatefulSet like so:

kind: StatefulSet
metadata:
  name: greymatter-operator
...
spec:
  template:
    spec:
      containers:
        name: operator
        ...
        env:
          - name: GREYMATTER_GIT_USER
            value: your-username
          - name: GREYMATTER_GIT_PASSWORD
            valueFrom:
              secretKeyRef:
                name: operator-gitops-basicauth-password
                key: password
                optional: false
        ...

and then (in this example) you would create the password secret manually like so after creating the gm-operator namespace and before launching the operator:

 kubectl create secret generic operator-gitops-basicauth-password \
   --from-literal=password='your-actual-password-here' \
   -n gm-operator

In addition to GREYMATTER_GIT_USER and GREYMATTER_GIT_PASSWORD, you may also specify GREYMATTER_GIT_REMOTE_CA (a path to a file, defaults to the default OS CA bundle) to pass a trusted CA bundle to the operator for TLS server verification, or GREYMATTER_GIT_TLS_SKIP_VERIFY (a boolean, default false) to skip server verification entirely (insecure and discouraged for production).

Next Steps

Deploy a Service