1. Common service configs
   1. Data protection and security
2. Communication and API endpoints
   1. RpcClientOptions.json and RpcServerOptions.json
   2. Logging options
3. Config Monitor
4. Startup jobs in the init container
5. Core Service Defaults

Common service configs

All backend services in the V-Raptor use a common set of configuration files. These files dictate how the services communicate and authenticate with each other as well as output application logs.

Various defaults can be configured prior to installation so that all services deployed by the V-Raptor’s Deployment agent start with the same basic set of options already applied.

The relevant default values that can be adjusted are discussed in the following sections.

Data protection and security

File Name: DataProtectionOptions.json

In this file, the following defaults can be configured for all services:

• Minimum supported TLS version
• Whether or not to use CRLs when validating certificates¹
• Allowed cipher suites

The config file can resemble the following:

{
  "DataProtectionOptions": {
    "AllowInvalidCrl": true,
    "TlsVersion": "All",
    "AllowedCipherSuites" : []
  }
}

The supported TLS options are described in the table below:

The list of supported cipher suites can be found on the official Microsoft documentation site located at docs.microsoft.com

File Name: IdentityClientOptions.json

It is usually not necessary to add anything to this file. The main purpose is to provide the scheme used to talk to the Raptor’s identity service. In production this should always be https.

{
  "IdentityClientOptions": {
    "IdentityServiceURL": "https://localhost",
    "APIName": "RaptorRPC"
  }
}

Communication and API endpoints

File Name: KestrelOptions.json

This file configures the HTTP endpoints exposed by the service by default.

• The minimum HTTP version supported
• The maximum header sizes supported (optional)².
• The default scheme. This should always be https in production.

{
  "Kestrel": {
    "Limits": {
      "MaxRequestHeaderCount": 1000,
      "MaxRequestHeadersTotalSize": 5144576,
      "MaxRequestBufferSize": 5144576
    },
    "EndPoints": {
      "HttpsDefaultCert": {
        "Url": "https://localhost",
        "Protocols": "Http1AndHttp2"
      }
    }
  }
}

The following protocols can be set (source):

RpcClientOptions.json and RpcServerOptions.json

These files dictate the structure used for the RPC options and should match the specified RPC layer that the V-Raptor will use.

Note: At present this will always be gRPC.

File Name: RpcClientOptions.json

The RPC Client options file when using gRPC:

{
  "GrpcClientConnectionEndpointsOptions": {
    "Endpoints": {}
  }
}

The rest of the content will get populated as services are deployed.

File Name: RpcServerOptions.json

For the RPC server options file, the only field that can be adjusted is the response timeout.

{
  "GrpcServerHostOptions": {}
    "TimeoutMs": 10000
}

Logging options

File Name: LoggingOptions.json

This config file configures the default log levels for various software modules on each micro-service. Additional filters can be added as needed.

{
  "Logging": {
    "LogLevel": {
      "Default": "Information",
      "System": "Information",
      "Microsoft": "Information",
      "Some.Filtered.Namespace": "Error"
    }
  },
  "AllowedHosts": "*"
}

File Name: nlog.config

The V-Raptor uses a log extension called nlog. nlog provides a large number of configuration options which can be found here. You can configure the default log layouts you want to use for each new service on the V-Raptor by adjusting the nlog template config below. Additional log targets can also be added e.g. pushing to logstash or FluentD.

<?xml version="1.0" encoding="utf-8" ?>
<nlog xmlns="http://www.nlog-project.org/schemas/NLog.xsd"
      xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" autoreload="true">
    <targets async="true">
        <target name="logfile" xsi:type="File" fileName="${environment:RaptorEnvironmentOptions__DataPath}/Logs/log.txt" layout="${longdate}|${level:uppercase=true}|${logger}|${message} ${exception:format=tostring}" maxArchiveFiles="10" archiveAboveSize="1048576" archiveNumbering="Rolling" archiveEvery="None" />
        <target name="logconsole" xsi:type="ColoredConsole" layout="${longdate}|${level:uppercase=true}|${logger}|${message} ${exception:format=tostring}" />
        
        <!--Configure your network logger here e.g. fluentD -->
        <target name="udp" xsi:type="Network" address="udp://${environment:LogEndpoint}:${environment:LogPort}">
            <layout xsi:type="JsonLayout" includeAllProperties="true">
                <attribute name="timeStampUtc" layout="${date:universalTime=true:format=yyyy-MM-dd HH\:mm\:ss.fff}" />
                <attribute name="level" layout="${level:upperCase=true}"/>
                <attribute name="message" layout="${message}" />
                <attribute name="exception" layout="${exception}" />
                <attribute name="hostname" layout="${hostname}" />
                <attribute name="logger" layout="${logger}" />
                <attribute name="callsite" layout="${callsite}" />
                <attribute name="serviceName" layout="${environment:ServiceName}" />
            </layout>
        </target>
    </targets>

    <rules>
        <logger name="*" minlevel="Debug" writeTo="logconsole" />
        <logger name="*" minlevel="Debug" writeTo="logfile" />
        
        <!--Add your network logger here -->
        <logger name="*" minlevel="Debug" writeTo="udp" />
    </rules>
</nlog>

Config Monitor

Configuration files are mounted into each service through Kubernetes secrets and config maps. Since these files are mounted using symbolic links, the Raptor micro-services are not notified of file changes.

To combat this, each Raptor service has a small config monitor job that runs alongside it. Its job is to check for configuration changes from the Kubernetes file mounts, and apply the changes to files monitored by the Raptor service. The end result is that many configuration files can be modified without needing to restart the service.

The check period can be configured by setting the following variable in the monitor.sh script. If this is not set, the default of 30 seconds will be used.

The monitor can also be disabled completely if not required.

### Should config reloading be used. Set to 1 if not needed
DISABLE_MONITOR=0

### Interval at which the monitor job checks for changes. Uncomment to set
# MONITOR_INTERVAL=5

Startup jobs in the init container

The V-Raptor also includes an initialization container that runs when a service starts up. This container can be used to run any initialization logic that is required to complete before the service starts. By default, this script will ensure CA chains are installed on each service, and that the required directory structures and configs are in place. Additional rules can be added after the following line in the init.sh script:

# Copy configs
cp /app/Data/Config/* $RaptorEnvironmentOptions__DataPath/Config

#TODO: Add any other initialization logic

Note : Make sure the commands you run are available in the initialization container. A custom initialization container can be specified in KubernetesDeploymentOptions by changing the InitContainerImage field.

Core Service Defaults

The main Raptor service’s can also be given default configuration files. These files are located in the ServiceDefaults folder. More information is provided in the Configuring the installer section.