Skip to content

Configuration

Jump to bottom
Robert Hafner edited this page Nov 5, 2023 · 5 revisions

Both the Nebula Worker and the Nebula App services use the same configuration file. This file is formatted in YAML and has multiple sections that will need configuring.

Deploying Settings

Nebula has two ways to read settings- the filesystem and the AWS Secrets Manager.

File Based Settings

The Nebula configuration can be stored as a file that exists alongside the application itself. To tell Nebula where this file is simply define the SETTINGS environmental variable with the absolute path to the configuration file.

AWS Secrets Manager Based Settings

Nebula can also pull the configuration directly from the AWS Secrets Manager. This method is slightly more complicated but makes it far easier to deploy and upgrade Nebula using a container based approach.

  1. First create the settings file as you normally would.
  2. To upload the settings run ./bin/config_to_sm.sh /path/to/file NameOfSecret. The NameOfSecret value can be any string.
  3. Make sure that the "IAM Role" being used by Nebula has access to the secret.
  4. Set the environmental variable AWS_SECRETS_SETTINGS to the NameOfSecret from the previous step before launching Nebula.

That's it! The config_to_sm.sh script will create the secret if it doesn't exist or update it if it does. When Nebula starts up it will download the configuration file from the Secrets Manager.

Sections

General

  • site_name (Optionsl): Defaults to nebula. It is used for organizations with multiple Nebula installs. EC2 instances are tagged with this value and Nebula installs will only contain appropriated tagged instances.
  • site_title (Optionsl): Defaults to nebula. It is used to allow organizations with multiple Nebula installs to give them distinct titles in the web application.
  • secret_key: Used to secure a variety of secrets and must be unique per install. See below for an example method to generate this value.
  • filecache: Path for Nebula to store file based cache and session data. Using a location in /tmp is useful but means reboots will force a logout.

API

  • ssh_secret: When defined it is used to grant read only access to the public keys stored on this server. It is used to integrate with OpenSSH.

Celery

  • broker: A path to an AMQP broker, such as "amqp://rabbitmq:5672".
  • results: False, although this will likely change in a future version.

PostgreSQL

  • database: Database name.
  • username: Database user.
  • password: Database password.
  • host: Database host.

AWS

  • region: The region to launch instances into.
  • use_launch_templates: When true profiles will be disabled and launch templates will be used instead. This renders many of the other options below useless, as the values will be set in the launch templates instead.
  • ebs_optimized: Should instances be EBS optimized.
  • subnets: An array of subnets to launch machines into. They will be attempted in order, with failures (such as INSUFFICIENT_CAPACITY errors for specific availability zones) skipped over in favor of the next subnet.
  • security_group: The security group to launch the instance into.
  • auto_live: When set to True systems will automatically become available on launch. When disabled it will be the responsibility of the instance's provisioning script to set the Status tag to Live in order to make the machine available.
  • iam_instance_profile (optional): When set this IAM Instance Profile will be attached to the new instances.
  • instances (optional):
    • blacklist: An array containing instance families which Nebula should not use.
    • whitelist: If defined only instance families in this array will be used by Nebula.

LDAP

  • host: LDAP provider URI ('ldap://ldap').

  • bind_dn: The full DN of the bind user ('cn=admin,dc=example,dc=org').

  • bind_password: The bind user password.

  • username_attribute: The attribute used for the username ('cn').

  • user_base: The base dn for user objects ('ou=users,dc=example,dc=org').

  • group_object_class: The objects used to define groups ('posixGroup')

  • group_attribute: The attribute used for the group name ('cn')

  • group_base: The base dn for groups ('ou=groups,dc=example,dc=org')

  • banned_group: Users in this group will not be allowed to access the system.

  • admin_group: Users in this group can access all admin tools.

  • user_group: Users who are not admins must be in this group to access the system.

Email

It is not required to setup email but it it used by a few features.

  • host: SMTP Server Hostname.
  • username: Username for the smtp server.
  • password: Password for the smtp server.
  • email: The email address acting as the sender, in the full From format ("Nebula" <nebula@example.com>).

Notifications

  • threshold: The amount, in dollars, that a user's instances must be above to trigger a reminder email.

Generating a Secret Key

In a python shell (python -i):

import binascii
import os
binascii.hexlify(os.urandom(24))

Example Configuration

general:
  site_name: 'nebula'
  site_title: 'nebula'
  secret_key: 'CHANGE_THIS_PASSWORD'
  filecache: "/tmp/cache"

api:
  ssh_secret: 'changeme'

celery:
  broker: "amqp://rabbitmq:5672"
  results: False

postgres:
  database: 'nebula'
  username: 'nebula'
  password: 'nebula'
  host: 'database'

aws:
  region: 'us-east-1'
  ebs_optimized: False
  subnets:
    - 'subnet-12345678'
    - 'subnet-23456789'
    - 'subnet-34567890'
  security_group: 'sg-12345678'
  auto_live: True
  iam_instance_profile: False

ldap:
  host: 'ldap://ldap'
  bind_dn: 'cn=admin,dc=example,dc=org'
  bind_password: ''

  username_attribute: 'cn'
  user_base: 'ou=users,dc=example,dc=org'

  group_object_class: 'posixGroup'
  group_attribute: 'cn'
  group_base: 'ou=groups,dc=example,dc=org'

  banned_group: 'banned'
  admin_group: 'nebula_admins'
  user_group: 'nebula_users'

email:
#  domain:
#  username:
#  password:
#  email:

notifications:
#  threshold:
Clone this wiki locally