As Scalingo is marching towards ISO 27001 certification, we'll see in this article how we covered the case of one-off container audit logs.
ISO/IEC 27001 is an information security standard, part of the ISO/IEC 27000, of which the last version was published in 2013.
ISO/IEC 27001 specifies a management system that is intended to bring information security under management control and gives specific requirements. Organizations that meet the requirements may be certified by an accredited certification body following successful completion of an audit.
While it will be a long way before Scalingo is ready to be ISO 27001 certified, our strategy is to incorporate the ISO 27001 mindset in our corporate and tech development policy as early as possible.
In the ISO 27001 world, every action made on Scalingo should be traceable, be it an action taken by one of our customers or an action taken by our internal services or our tech team. Usually, to comply with the traceability of actions, an audit log is built: a backlog of all the actions done, including their input and ouput on the target system.
When your app is deployed on our infrastructure, the Procfile of your project is scanned and the different methods to start your project are registered and available for scaling in your dashboard.
For various reasons you may need to run other tasks in the environment of your application. Those tasks can be one shot/non interactive (lauching a rake task, a PHP Artisan command) or interactive (bash, Rails console).
Here is a sample video of the kind of operations you can achieve with one-off containers:
Other examples of one-off container are database consoles built-in the CLI.
While most frequent usages of one-off containers are achieved through the CLI, you can also create them with the One-off Containers API. Some of our customers have already built Functions-as-a-Service-like platform with this feature.
Let's get back to the main subject of this article, for security and auditing reasons, input/ouput of those one-off containers are required.
The audit logs are available in the Timeline of your app:
To get audit logs from a one-off container, the service responsible for running one-off adds a logging middleware through which every bytes sent by the client and every bytes sent by the server must go through. Those events are directly streamed to a local Redis server, used as cache. As soon as the one-off is stopped, the same service will query Redis to fetch those raw events and build the audit log. The constructed log is an a JSON file which will be encrypted and stored.
When requested, those logs will be downloaded and decrypted on the fly before being shown on the dashboard. For performance reasons, if the audit logs are bigger that 1 MB, the logs wont be displayed in the dashboard but a download link will be displayed to download the raw file.