Overview

Kriten is a code execution platform. It is written for and runs on kubernetes as a cloud native application. Kriten exposes containerized applications written in any modern languagues as no-code REST API endpoint, with local or/and AD authentication and granular RBAC it allows requester to execute that code as a kubernetes job and to get result asynchronously.

Key features:

  • No-code REST API exposure of custom application and scripts execution.

  • Local or/and AD user authentication.

  • Granular RBAC to permission CRUD operations against Kriten configured objects.

  • Kriten scales with Kubernetes.

Permission to perform configuration activities against those objects is granted to local or AD users and controlled via granular RBAC.

Kriten is API driven for easy integration with other systems.

Each Kriten task defines a URL that authorised entities can use to launch a job.

The diagram depicts Jenkins launching an Ansible playbook, and GitLab launching some python code.

The requesting systems, Jenkins and GitLab in this case, do not need access to system accounts or the source playbook/code.

Pre-requisites for Applications & Scripts:

  • If target application needs secret(s), those are supplied at the time of Task creation and will be stored as Kubernetes Secrets. At the time of execution of the jobs against that Task, job container will get those secrets mapped as files in /etc/secret directory and as environmental vars. Application would need to read those files or environmental vars to use secrets.

  • If target application needs input parameters for execution, those are supplied at the time of Job submission and will be mapped as Environmental var 'EXTRA_VARS' to the job container. Application will need to read environmental var 'EXTRA_VAR' in format of json to consume those parameters.

Main components:

Runner

Runner object defines the following:

  • Git project repository, branch (default is ”main”) and access password/token if repository is private.

  • Container image with all libraries, packages and dependencies, needed to run application(s) in the repository.

Task

Task is a child object of Runner and defines the following:

  • Command to execute application or script from associated by Runner repository in the container.

  • Secrets are optionally provided, which are stored as kubernetes secrets and mapped to job containers at the time of execution as files in /etc/secret/ directory and as environmental variables.

  • Schema in OpenAPI specification is optionally provided, which allows Kriten to validate input parameters against schema and deny job creation if those are not matching the schema.

Multiple tasks can be associated with the same Runner. It allows exposing same script or application with different parameters as separate tasks, i.e. one allowing only perform read kind operation and another to do write operation and to control via RBAC, which users are allowed to execute jobs against those tasks.

Kriten supports two modes for tasks: synchronous and asynchronous, controlled by parameter “synchronous”: “true|false”. In synchronous mode, Kriten will wait a period of time for a job completion (default is 20 seconds after start of the job container) and will return result back. In asynchronous mode, on successful submission of a job, Kriten will return job id, which then will need to be queried to get result of that job.

Kriten can return custom data in a result of a job by capturing stdout output from application or script of json string delimited by "^JSON”.

Job

Jobs are triggered against defined Tasks. Permission is controlled via RBAC.

Executor of a Job may need to supply Input parameters as it may be required by application or script at the time of execution. Those Input parameters are provided in the body of REST API request, validated against schema if it is defined, and exposed to job container as Environmental var 'EXTRA_VARS'.