employees-api settings | RigFabTech docs

What employees-api needs from you before it installs. It goes in one small file, employees-api.yaml, which you pass to helm install and helm upgrade after site.yaml, as Install shows.

Starter file

employees-api.yaml holds every setting on this page with its description. Save it, replace each <PLACEHOLDER> and remove the optional lines you don't need. employees-api.schema.json describes the file to editors that check YAML against a JSON schema.

Secret settings

Passwords, keys and other values to keep private.

Name	Required	Description
`EMPLOYEES_API_KEY`	Yes	A long random key of your choosing that other products send to read the employee list or start a sync; give the same value to each product that reads employees
`ENTRA_TENANT_ID`	Yes	Your Microsoft Entra tenant's ID
`ENTRA_CLIENT_ID`	Yes	The application (client) ID of the app registration employees-api uses at Microsoft Entra ID to read your people and to sign administrators in
`ENTRA_CLIENT_SECRET`	Yes	The client secret of the app registration employees-api uses at Microsoft Entra ID
`ENTRA_GROUP_ID`	Yes	The object ID of the Microsoft Entra group your employees belong to; each one's job title, email, phone and department are read from its members
`ECI_PATH`	No	The host name of your E2 API server, which employees-api reaches over plain HTTP; give it with its port if it has one and without http://, for example e2.example.com; leave the four ECI values out to keep the employee IDs already stored
`ECI_API_KEY`	No	The API key of your E2 API
`ECI_USERNAME`	No	The E2 user name employees-api logs in to the E2 API with
`ECI_HASHED_PASSWORD`	No	The password of the E2 user named in ECI_USERNAME, in the hashed form the E2 API's login takes
`HOMEBASE_API_KEY`	Yes	The API key of your Homebase account; the list of who works for you is read with it
`HOMEBASE_LOCATION_UUID`	Yes	The UUID of the Homebase location whose employees are read
`NOTIFICATION_SERVICE_CLIENT_ID`	Yes	The application (client) ID of notification-service's app registration at Microsoft Entra ID; employees-api uses it to send notification-service alerts about employee records that need review

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, employees-api.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 employees-api-settings --namespace rft-app-employees-api --from-env-file=employees-api.env
rm employees-api.env

In employees-api.yaml, give only the Secret's name:

secrets:
  existingSecret: employees-api-settings

To 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-employees-api get pods shows CreateContainerConfigError or Init:CreateContainerConfigError, and kubectl --namespace rft-app-employees-api 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-employees-api rollout restart deployment.

To get started, in the values file. Under secrets in employees-api.yaml, as the starter file has them. The chart keeps them in the Secret employees-api-env.

Made for you

The platform makes these once and keeps them in the Secret employees-api-generated. There is nothing to set.

SESSION_SECRET

In site.yaml

employees-api answers on employees-api.<domain>, under your global.rigfab.domain. To give it another name, set global.rigfab.hosts.employees-api to the full host name.

employees-api reaches these services on your network. Say where each answers, once, in site.yaml; the products may reach only those addresses and ports:

global:
  rigfab:
    site:
      destinations:
        e2-web: {cidrs: [<ADDRESS>/32], ports: [<PORT>]}

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/employees-api/charts/employees-api --version <VERSION> --release employees-api --namespace rft-app-employees-api --values site.yaml --values employees-api.yaml

It 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.