notification-service settings
What notification-service needs from you before it installs. It goes in one small file, notification-service.yaml, which you pass to
helm install and helm upgrade after site.yaml, as Install shows.
Starter file
notification-service.yaml holds every setting on this page with its description. Save it, replace each
<PLACEHOLDER> and remove the optional lines you don't need.
notification-service.schema.json describes the file to editors that check YAML against a JSON schema.
Settings
Plain values, under settings in notification-service.yaml.
| Setting | Required | Default | Description |
|---|---|---|---|
settings.brandColor | No | "#1d4ed8" | The colour of the accent bar and buttons in notification emails, as a six-digit hex code such as #1d4ed8; white text must stay readable on it (4.5 contrast), or no email is sent until you correct it |
settings.companyName | Yes | Your company's name as notification emails show it in their footer | |
settings.internalNotifyTo | Yes | The email addresses that get system alerts, separated by commas | |
settings.mailFrom | Yes | The address of the mailbox notification emails are sent from, such as notifications@example.com; the app registration in AZURE_CLIENT_ID must be allowed to send as it |
Secret settings
Passwords, keys and other values to keep private.
| Name | Required | Description |
|---|---|---|
AZURE_CLIENT_ID | Yes | The application (client) ID of the Microsoft Entra app registration notification-service sends mail and looks up people and groups with; it needs the Microsoft Graph application permissions Mail.Send, User.Read.All and GroupMember.Read.All, with admin consent |
AZURE_CLIENT_SECRET | Yes | A client secret of the app registration in AZURE_CLIENT_ID, created under its Certificates & secrets; give the secret's Value, not its Secret ID |
AZURE_TENANT_ID | Yes | Your Microsoft Entra tenant's ID, for the tenant that holds the app registration in AZURE_CLIENT_ID |
ENTRA_CLIENT_ID | Yes | The application (client) ID of the Microsoft Entra app registration that stands for notification-service itself; the other products ask for tokens for it when they call notification-service |
ENTRA_TENANT_ID | Yes | Your Microsoft Entra tenant's ID, for the tenant the other products get their tokens for notification-service from |
Give them in one of two ways, never both.
In production, in a Secret of your own. A values file with passwords in it tends to end up in git, and Helm
keeps a copy of the values you pass in its release record in the cluster. Write the values to a file,
notification-service.env, one NAME=value per line with each value as it is, without quotes, then create the Secret and delete
the file:
kubectl create secret generic notification-service-settings --namespace rft-app-notification-service --from-env-file=notification-service.env
rm notification-service.envIn notification-service.yaml, give only the Secret's name:
secrets:
existingSecret: notification-service-settingsTo keep the Secret in git or a secret store instead, create it with External Secrets Operator, SOPS or Sealed Secrets, with the same keys.
The Secret needs a key for every required name above. When one is missing, the product's pods don't start:
kubectl --namespace rft-app-notification-service get pods shows CreateContainerConfigError or Init:CreateContainerConfigError, and
kubectl --namespace rft-app-notification-service describe pods names the missing key. Add it and the pods start by themselves.
After you change a value in the Secret, restart the product with
kubectl --namespace rft-app-notification-service rollout restart deployment.
To get started, in the values file. Under secrets in notification-service.yaml, as the starter file has them. The chart
keeps them in the Secret notification-service-env.
Check before you install
Once the base chart is installed, and before you install or upgrade this product:
rft check --chart oci://registry.rigfab.com/rft/apps/notification-service/charts/notification-service --version <VERSION> --release notification-service --namespace rft-app-notification-service --values site.yaml --values notification-service.yamlIt renders the chart with your files and asks the cluster whether it would accept the result, and changes
nothing. A setting that is missing or misspelt in your files stops it with a message that names the setting. It
doesn't look inside a Secret of your own. A misspelt name under global.rigfab is the base chart's to refuse, so
check site.yaml with the base chart after every change to it, as Install shows.