kore

An easy to use, scalable and secure web application framework for writing web APIs in C.
Commits | Files | Refs | README | LICENSE | git clone https://git.kore.io/kore.git

kore.conf.example (11928B)



      1 # Example Kore configuration
      2 
      3 # Below you will find all available configuration
      4 # options for Kore. Options which have a default value
      5 # and can be left out of the configuration are commented
      6 # out with their default value specified.
      7 
      8 # Maximum length to queue pending connections (see listen(2))
      9 # MUST be set before any bind directive.
     10 #socket_backlog			5000
     11 
     12 # Server configuration.
     13 server tls {
     14 	bind		127.0.0.1 443
     15 	#unix		/var/run/kore.sock
     16 }
     17 
     18 #server notls {
     19 #	bind		127.0.0.1 80
     20 #	tls		no
     21 #}
     22 
     23 # Kore can have multiple settings for each processes that run under it.
     24 # There are 3 different type of processes:
     25 #
     26 #	1) A worker process, these handle the HTTP requests and your code
     27 #	   runs inside of these.
     28 #	2) A keymgr process, this handles your domain private keys
     29 #	   and signing during the TLS handshakes. It also holds your
     30 #	   ACME account-key and will sign ACME requests.
     31 #	3) An acme process, this talks to the ACME servers.
     32 #
     33 # You can individually turn on/off chrooting and dropping user
     34 # privileges per process. The -n and -r command-line options
     35 # are a global override for skipping chroot or dropping user
     36 # permissions on all processes.
     37 #
     38 # If no root/runas options are set in a process, it will inherit the
     39 # default values from the worker processes.
     40 #
     41 # The worker processes will get the current working directory or
     42 # current user if no options where specified for it.
     43 #
     44 # Configures the worker processes.
     45 privsep worker {
     46 	# The user the workers will run as.
     47 	runas		kore
     48 
     49 	# The root directory for the worker processes, if chroot isn't
     50 	# skipped, this is the directory it will chroot into.
     51 	#
     52 	# If not set, Kore will take the current working directory.
     53 	root		/var/chroot/kore
     54 
     55 	# We could configure this process to not chroot and only
     56 	# chdir into its root directory.
     57 	#skip		chroot
     58 }
     59 
     60 # Configures the keymgr process.
     61 #	If TLS is enabled you will need to specify paths to the domain
     62 #	certificate and key that Kore will load. This loading is done
     63 #	from the keymgr (separate process) and all paths must be relative
     64 #	to the keymgr process its root configuration option.
     65 privsep keymgr {
     66 	# The user the keymgr will run as.
     67 	runas		keymgr
     68 
     69 	# The root directory for the keymgr process. In this example
     70 	# we do not turn off chroot for this process so the keymgr
     71 	# will chroot into this directory.
     72 	root		/etc/keymgr
     73 }
     74 
     75 # Configure Kore to log all worker output to a certain file.
     76 #
     77 # This forces all logs from the workers to be written to this file
     78 # instead of stdout. Note that this is not the actual access log.
     79 #
     80 # Any message logged by your application with kore_log() will also
     81 # appear under here.
     82 #logfile /var/log/kore.log
     83 
     84 # How many worker processes Kore will spawn. If the directive
     85 # worker_set_affinity is set to 1 (the default) Kore will automatically
     86 # pin these worker processes to different CPU cores in your system.
     87 # NOTE: If you set this to the maximum number of cores you have
     88 # in your system (or more) you might consider turning off affinity
     89 # if you are running CPU heavy services on the same machine.
     90 workers		4
     91 
     92 # The number of active connections each worker can handle.
     93 # You might have to tweak this number based on your hardware.
     94 #worker_max_connections		512
     95 
     96 # Limit of maximum open files per worker.
     97 #worker_rlimit_nofiles		768
     98 
     99 # Limit the number of new connections a worker can accept
    100 # in a single event loop. By default Kore will accept as
    101 # many new connections it can up to worker_max_connections.
    102 #
    103 # NOTE: If you are running benchmark tools that throw all
    104 # connections at Kore at the same time (when they are less
    105 # then worker_max_connections) or you have an actual reason
    106 # to not spend too much time in the accept loop this setting
    107 # will make a HUGE positive difference.
    108 
    109 # Number of accept() calls a worker will do at most in one go
    110 # before releasing the lock to others.
    111 #worker_accept_threshold		16
    112 
    113 # What should the Kore parent process do if a worker
    114 # process unexpectedly exits. The default policy is that
    115 # the worker process is automatically restarted.
    116 #
    117 # If you want the kore server to exit if a worker dies
    118 # you can swap the policy to "terminate".
    119 #worker_death_policy		restart
    120 
    121 # Workers bind themselves to a single CPU by default.
    122 # Turn this off by setting this option to 0
    123 #worker_set_affinity		1
    124 
    125 # Store the pid of the main process in this file.
    126 #pidfile	kore.pid
    127 
    128 # If TLS is enabled you can specify a file where Kore will read
    129 # initial entropy from and save entropy towards when exiting.
    130 #
    131 # Note that if you enable this you must provide the first iteration
    132 # of this file by generating 1024 cryptographically safe random bytes
    133 # and writing them to the file specified.
    134 #
    135 # Kore will refuse to start if the specified file does not exist,
    136 # is of the wrong size or cannot be opened in anyway.
    137 #
    138 # NOTE: This file location must be inside your chrooted environment.
    139 #rand_file	random.data
    140 
    141 # Filemap settings
    142 #	filemap_index	Name of the file to be used as the directory
    143 #				index for a filemap.
    144 #filemap_index index.html
    145 
    146 # HTTP specific settings.
    147 #	http_header_max		Maximum size of HTTP headers (in bytes).
    148 #
    149 #	http_header_timeout	Timeout in seconds for receiving the
    150 #				HTTP headers before the connection is closed.
    151 #
    152 #	http_body_max		Maximum size of an HTTP body (in bytes).
    153 #				If set to 0 disallows requests with a body
    154 #				all together.
    155 #
    156 #	http_body_timeout	Timeout in seconds for receiving the
    157 #				HTTP body in full before the connection
    158 #				is closed with an 408.
    159 #
    160 #	http_body_disk_offload	Number of bytes after which Kore will use
    161 #				a temporary file to hold the HTTP body
    162 #				instead of holding it in memory. If set to
    163 #				0 no disk offloading will be done. This is
    164 #				turned off by default.
    165 #
    166 #	http_body_disk_path	Path where Kore will store any temporary
    167 #				HTTP body files.
    168 #
    169 #	http_keepalive_time	Maximum seconds an HTTP connection can be
    170 #				kept alive by the browser.
    171 #				(Set to 0 to disable keepalive completely).
    172 #
    173 #	http_hsts_enable	Send Strict Transport Security header in
    174 #				all responses. Parameter is the age.
    175 #				(Set to 0 to disable sending this header).
    176 #
    177 #	http_request_limit	Limit the number of HTTP requests workers
    178 #				can queue up.
    179 #
    180 #	http_request_ms		The number of milliseconds workers can max
    181 #				spend inside the HTTP processing loop.
    182 #
    183 #	http_server_version	Override the server version string.
    184 #
    185 #http_header_max	4096
    186 #http_header_timeout	10
    187 #http_body_max		1024000
    188 #http_body_timeout	60
    189 #http_keepalive_time	0
    190 #http_hsts_enable	31536000
    191 #http_request_limit	1000
    192 #http_request_ms	10
    193 #http_body_disk_offload	0
    194 #http_body_disk_path	tmp_files
    195 #http_server_version	kore
    196 
    197 # Websocket specific settings.
    198 #	websocket_maxframe	Specifies the maximum frame size we can receive
    199 #	websocket_timeout	Specifies the time in seconds before a websocket
    200 #				connection would be closed due to inactivity.
    201 #websocket_maxframe	16384
    202 #websocket_timeout	120
    203 
    204 # Configure the number of available threads for background tasks.
    205 #task_threads		2
    206 
    207 # Load modules (you can load multiple at the same time).
    208 # An additional parameter can be specified as the "onload" function
    209 # which Kore will call when the module is loaded/reloaded.
    210 load contrib/examples/generic/example.module	example_load
    211 
    212 # Load a python file (if built with PYTHON=1)
    213 #python_import src/index.py example_load
    214 
    215 # Validators
    216 #	validator	name	type	regex|function
    217 #
    218 validator	v_example	function	v_example_func
    219 validator	v_regex		regex		^/test/[a-z]*$
    220 validator	v_number	regex		^[0-9]*$
    221 validator	v_session	function	v_session_validate
    222 
    223 # Specify what TLS version to be used. Default is TLSv1.3 if available.
    224 # Otherwise it will use TLS 1.2.
    225 # Allowed values:
    226 #	1.3 for TLSv1.3 (default, if available)
    227 #	1.2 for TLSv1.2
    228 #	both for TLSv1.2 and TLSv1.3
    229 #tls_version	1.3
    230 
    231 # Specify the TLS ciphers that will be used.
    232 #tls_cipher	AEAD-AES256-GCM-SHA384:AEAD-CHACHA20-POLY1305-SHA256:AEAD-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256
    233 
    234 # Required DH parameters for TLS if DHE ciphersuites are in-use.
    235 # Defaults to SHARE_DIR/ffdhe4096.pem, can be overwritten.
    236 #tls_dhparam	/usr/local/share/kore/ffdhe4096.pem
    237 
    238 # OpenBSD specific settings.
    239 # Add more pledges if your application requires more privileges.
    240 # All worker processes call pledge(2) after dropping privileges
    241 # (even if -rn was specified).
    242 # By default Kore will use the following promises: "stdio rpath inet error"
    243 #pledge dns wpath
    244 
    245 # seccomp specific settings.
    246 # If set to "yes", Kore will trace its child processes and properly
    247 # log seccomp violations while still allowing the syscalls.
    248 #seccomp_tracing	yes
    249 
    250 # Authentication configuration
    251 #
    252 # Using authentication blocks you can define a standard way for
    253 # Kore to validate your users. In the example below we create
    254 # a authentication block called auth_example, which requires
    255 # a cookie (session_id) to be set.
    256 #
    257 # If no cookie is present or the cookie is not valid according
    258 # to the set validator, Kore will redirect the browser to the
    259 # URI set in authentication_uri.
    260 #
    261 # Page handlers can be bound to authentication by specifying
    262 # authentication block at the end of the page directive (see below).
    263 authentication auth_example {
    264 	# The authentication type denotes the way the user should
    265 	# be authenticated.
    266 	#
    267 	# Allow values:
    268 	#	- cookie (checks for the cookie presence + pass to validator)
    269 	#	- header (checks for header presence + pass to validator)
    270 	#	- request (passes the http_request to the validator)
    271 	#
    272 	# Use cases for request could for example be IP based ACLs or
    273 	# any other criteria that can be extracted from a http_request.
    274 	#
    275 	# The request type does not need an authentication_validator.
    276 	#
    277 	authentication_type		cookie
    278 
    279 	# The name of whatever we are looking for.
    280 	authentication_value		session_id
    281 
    282 	# The validator that will be called to verify the cookie.
    283 	# Note this is YOUR validator, Kore does not have built-in
    284 	# session support. You must add this manually using your
    285 	# preferred method (Storing it in postgres, redis, ...)
    286 	authentication_validator	v_session
    287 
    288 	# The URI Kore will redirect to if a authentication fails.
    289 	# If this is not set, Kore will return a simple 403.
    290 	authentication_uri		/private
    291 }
    292 
    293 # Domain configuration
    294 #
    295 # Each domain configuration starts with listing what domain
    296 # the directives that follow are to be applied upon.
    297 #
    298 # Additionally you can specify the following in a domain configuration:
    299 #
    300 #	accesslog
    301 #		- File where all requests are logged.
    302 #
    303 #	NOTE: due to current limitations the client_verify CA path
    304 #	MUST be in the 'root' of the Kore workers, not the keymgr.
    305 #
    306 #	client_verify [CA] [optional CRL]
    307 #		- Turns on client verification, requiring the client to
    308 #		  send a certificate that will be verified by the given CA.
    309 #	client_verify_depth [depth]
    310 #		- Configure the depth for x509 chain validation.
    311 #		  By default 1.
    312 #
    313 # Routes
    314 #
    315 # Routes can be a static path or a POSIX regular expression.
    316 #
    317 # route /path {
    318 #	handler myhandler
    319 #	methods get post
    320 #	...
    321 # }
    322 #
    323 
    324 # Example domain that responds to localhost.
    325 domain localhost {
    326 	attach		tls
    327 
    328 	certfile	cert/server.crt
    329 	certkey		cert/server.key
    330 	accesslog	/var/log/kore_access.log
    331 
    332 	route / {
    333 		handler index_page
    334 		methods get
    335 	}
    336 
    337 	route /login {
    338 		handler login_do
    339 		methods post
    340 		validate post username v_username
    341 		validate post passphrase v_passphrase
    342 	}
    343 
    344 	route /mypages/ {
    345 		handler mypages_index
    346 		methods get
    347 		authenticate auth_example
    348 	}
    349 
    350 	# Allow access to files from the directory route_files via
    351 	# the /files/ URI.
    352 	#
    353 	# Note the directory given must be relative to the root configuration
    354 	# option.
    355 	filemap		/files/			static_files
    356 }
    357 
    358 # Example redirect 80->443.
    359 #domain localhost {
    360 #	attach		notls
    361 #
    362 #	# specific redirect with a capture group and arguments
    363 #	redirect	^/account/(.*)$	301	https://localhost/account/$1
    364 #
    365 #	# redirect the others back to root.
    366 #	redirect	^/.*$		301	https://localhost
    367 #}