Glasswall Halo FAQs

1. The file is sent to the REST API.
2. The file is stored on a persisted volume within the cluster.
3. A message is sent to the engine service to process the file.
4. The engine service receives the message to process a file.
5. That file is read from the persisted volume and is then processed by the Glasswall engine.
6. The clean file and analysis report are then stored in the persisted volume.
7. A message is sent to the report aggregator so the engine report can be generated.
8. A message is then sent back to the API from the engine service.
9. The API receives the message from the engine and reads either the clean file, report, or both from the persisted volume and generates the correct response to the client.
10. A message is then sent to the report aggregator from the API.
11. The report aggregator receives this message and generates a report from the analysis file and the API.
12. Reports are then uploaded to the configured storage.
13. Finally the original file, clean file, and analysis report are deleted from the persisted volume.

Original files, clean files, and analysis reports are stored in a persisted volume backed by either Azure File Share (Azure) or Amazon Elastic Block Store (AWS).

Reports can be stored in Azure Blob Storage (Azure), S3 (AWS), or a persisted volume.

Original files, clean files, and analysis reports are stored until the report generation is complete.

A maximum of 5 levels of nested archives are supported by Glasswall Halo.

The following archive types are supported in Glasswall Halo: Zip, Tar, Zip, 7Zip, Rar.

Allow - 0

Sanitise- 1

Disallow - 2

Within the error response, Glasswall Halo returns a "code" which indicates a particular scenario. 

Error codes will start with the HTTP response code and include a number to indicate the specific error. For more information please refer to our API documentation.

Yes, the current configuration includes contingency for workloads that are more challenging than the average file. Whilst it may be possible to increase the replicas count and to observe improved performance, the consequence might be increased errors if the concurrent load depleted the available memory.

This is possible and would therefore allow the replicas count per node to be amended without necessarily experiencing any scarcity of compute resources. An obvious downside of assigning more workloads to a single node is the size of the blast radius should a node fail. Increasing the node count may achieve the same objective with less risk.

The CDR process needs to create an intermediate representation of the original file. This may be much larger that the original file. We have assigned reserve values to ensure that multiple large files can be processed.

Glasswall provides the customer with the entitlement to process a number of files or an amount of data each day. Today Glasswall does not impose a technical limitation on overconsumption of the license entitlement. However, over-consumption would represent a contractual violation of the licencing agreement. Glasswall will be introducing a license management layer into Glasswall Halo which imposes limitations of use according to the license entitlements.

Today there is no limitation on the number of Engine calls that may be made in a given time frame, beyond the base configuration that is provided in the Helm Charts. In the future, a license management mechanism may throttle throughput to pro-rate hourly capacity with the daily peak capacity that has been purchased.

1 GB. There may be examples of files that are impossible to CDR without allocating very large amounts of memory. CDR in general requires that an intermediate representation of a file is created. The memory required for the model can be a number of times larger than the original file. Depending on the structure of the underlying file, memory requirements may vary.

The report aggregator is responsible for generating service and analysis reports. Service reports will provide information on the service events for a particular file and analysis reports are a JSON representation of the Glasswall engine analysis report.

These reports are stored in either Blob storage, S3 or PV depending on what you have configured it to. For PV's the reports are stored in the path configured on the helm charts, this defaults to '/data/reports'. For Blob they are stored in the container with the name based on the helm chart configuration, this defaults to 'cdr-reports'. For S3 they are stored in the bucked configured in the helm charts, this defaults to 'reports'.

Glasswall is the world's premier CDR solution provider. Glasswall is very cautious about the use of 3rd party software dependencies general. We employ a mixture of static analysis, software composition analysis and infrastructure as code automated scanning to ensure that the 3rd party components that we use, do not introduce security flaws. Most software development today, incorporates 3rd party libraries into software applications and Glasswall is no different in this regard. We are however explicit about what these dependencies are and have zero tolerance for insecure software.

Glasswall generates SBOMs for the services that comprise the Halo deployment. These can be made available on request.

Yes that is correct.

Glasswall Halo is designed to be run in a secure environment, therefore none of your data is sent to Glasswall. Glasswall reserves the right to request summary log information to verify license conformance but data does not leave the environment without intervention by the system owner.

In the future, most of the services will use a hardened Alpine base image. Where possible we implement CIS (Centre for Internet Security) guidelines for hardening. Alpine provides a small Linux distribution with a minimised attack surface which is attractive from both a performance and security perspective.

When Halo is overloaded with huge number of API requests the queue will be built up with the messages and 429 status code will be seen. The messages will be eventually consumed by the system and it will come back to normal state. If it takes long time to process the messages in the queue and if you wish to bring the system back to normal state and also ok with loosing messages in the RabbitMQ queue, purge the queue to delete all messages in the queue.

kubectl exec -ncdrplatform -it rabbitmq-server-0 -c rabbitmq -- rabbitmqctl purge_queue engine-request-queue