Note: All of the following YAML options can be set in
/etc/sicura/sicura-console.yaml
Any other options are set from within the Console UI.
The Sicura Console is built on a framework that lets developers easily implement new plugins for additional functionality. This also allows users to pick the parts of the Console they want to use and omit the pieces they don’t want.
Sicura Console comes pre-loaded with multiple plugins. By default all plugins are loaded. If this is not the desired behavior, setting main.load_all_plugins = false
in the sicura-console.yaml
file will turn off this feature. You can then add the plugins you’d like to load to the plugins
array. For example, if you wanted to just load the GitLab and Slack plugins, your sicura-console.yaml
would include the following:
main.load_all_plugins: false
plugins:
- 'gitlab'
- 'slack'
The packaged plugins for the Sicura Console include:
Required (these plugins are required for the console to run properly and are loaded by default):
Optional (these plugins are generally broken down into notification and authentication providers):
Notification Providers - Will submit a notification specific to whatever platform is tied to this plugin whenever a relevant action is completed
Authentication Providers - Allow for authentication into the Console
Once properly configured, the new notification provider will appear anywhere in the Console that supports notifications. For example inside the Report Generator drawer, “Notify on Completion” will contain all notification providers set up for the Console.
The email plugin is set-up from inside the Console UI.
Navigate to Administration -> Notifications
, then click Create a New Notification
. Inside the drawer, give the new provider a name and select email
from the dropdown.
NOTE: If using Gmail configuration:
As of May 30, 2022 Google removed the option for users to enable less secure apps. To continue using Gmail, you must enable 2-Step Verification and use an application password.
Example configuration:
server: smtp.gmail.com
port: 587
username: the email you want to use to send emails
password: password for that email
interface: smtp for smtp server
encryption_method: TLS/STARTTLS
authentication_method: plain
recipient: email of the person receiving email
cc: (optional) additional recipient email
bcc: (optional) additional recipient email
The GitLab plugin is set-up from within the Console UI.
Navigate to Administration -> Notifications
, then click Create a New Notification
. Inside the drawer, give the new provider a name and select gitlab
from the dropdown.
Required parameters:
GitLab URL: API URL for your GitLab instance (i.e. https://gitlab.example.com/api/v4)
Access Token: Token of a user with rights to create issues
Project ID: can be found on the project you wish to generate the issue for
Project labels: labels that should be assigned to the issue
Assignee ID: user ID to assign the issue to
Milestone ID: ID of the milestone to be assigned to issue
The Slack plugin is set-up from inside the Console UI.
Navigate to Administration -> Notifications
and click Create a New Notification
. Inside the drawer, give the new provider a name and select slack
from the dropdown.
Example configuration:
oauth_token: (token provided by the bot configuration)
channel: #sicura-notifications (or some other channel)
Notice: Although it is possible to add directory services to Sicura Console using the yaml configuration, it is highly recommended to implement them using the user interface.
The LDAP plugin is installed in Sicura Console by default.
A directory service can be added by clicking Create New Entry in the Directory Services page under the Administration tab.
sicura-console.yaml
To configure a directory service in the sicura-console.yaml
, add main.directory_services
.
Each directory service is added as an element to main.directory_services
and take the following parameters:
name
- The canonical name of the service, this is the name that is shown when listed as a domain on the Sicura Console login page
Example: name: "Vagrant LDAP Test Server"
auth_provider
- The authentication provider to use
Example: auth_provider: "ldap"
create_user
- Specifies whether or not to automatically create a new Sicura Console user on successful login with an unlinked account
Example: create_user: true
settings
- A hash of additional plugin specific options
To add a new entry, click Create New Entry, select ldap as the Service Provider, and fill in the relevant details.
An example of two valid LDAP configurations:
main.directory_services:
- name: "Vagrant LDAP Test Server"
auth_provider: 'ldap'
create_user: true
settings:
search_base: "ou=People,dc=jaeger,dc=local"
search_filter: ''
login_attribute: 'uid'
host: "127.0.0.1"
port: 9080
binddn: ''
binddn_password: ''
- name: "Staging LDAP Test Server"
auth_provider: 'ldap'
create_user: true
settings:
search_base: "ou=People,dc=staging,dc=local"
search_filter: '(&(objectClass=person)(objectClass=user))'
login_attribute: "uid"
host: "192.168.0.27"
port: 9080
binddn: "cn=admin,dc=staging,dc=local"
binddn_password: 'Pas$word1'
The following are specific settings related to LDAP authentication, and are located in the settings
hash of the file.
search_base
- The organization unit and domain component string
search_filter
- The filter to narrow down results
(&(objectClass=person)(objectClass=user))
will be usedlogin_attribute
- The attribute by which user accounts will be looked up in the LDAP server
host
- The IP or domain of the target LDAP server
port
- The port to connect to the target LDAP server
binddn
- The full path to the object you are authenticating against
binddn_password
- The password for authentication
Note: Every LDAP setting except for
search_filter
must be configured. Use an empty string if a setting is not in use.Active Directory
Using the Active Directory User Interface
To add a new entry, click Create New Entry, select active directory as the Service Provider, and fill in the relevant details. The required connection details are the same as an LDAP provider, the primary difference being the login attribute
is samaccountName
instead of uid
.
main.directory_services:
- name: "Company Active Directory"
auth_provider: 'ldap'
create_user: true
settings:
search_base: "ou=People,dc=staging,dc=local"
search_filter: '(&(objectClass=person)(objectClass=user))'
login_attribute: "samaccountName"
host: "192.168.0.27"
port: 636
binddn: "cn=admin,dc=staging,dc=local"
binddn_password: 'Pas$word1'
To add a new entry, click Create New Entry, select google auth as the Service Provider, and fill in the relevant details.
The following parameters must be set in order for Google OAuth to correctly operate.
client_id
client_secret
domain
These are provided by Google when registering an API to use for Google OAuth.
When create_new_user is set to true
, Sicura Console will generate a new Console User if a user uses a Google login not already linked to a Sicura Console account
An example of what the configuration may look like:
main.directory_services:
- name: "Google OAuth Login Config"
auth_provider: 'google auth'
create_user: true
settings:
client_id: <clientid>.apps.googleusercontent.com
client_secret: <client secret>
domain: example.com