SecretVM provides a built-in log forwarding feature that allows you to stream all system and Docker container logs directly to a log aggregator of your choice.
This feature uses Fluent Bit to collect and forward logs in a structured JSON format. It is designed to be compatible with any aggregator that accepts data over HTTP, such as VictoriaLogs, Loki, or Elasticsearch.
To enable log forwarding, you must add a set of environment variables to your main .env configuration file.
Mandatory Variables
These variables are required to enable the log forwarding service.
Optional Variables
These variables allow you to configure security (TLS and Basic Auth) and customize the destination URI.
How to view SecretVM Logs
Logs are an invaluable source of information about the operation of any kind of software, and are widely used by developers to diagnose issues and monitor performance.
In SecretVM, logs can be accessed separately for each running container, and through 3 different modalities.
Viewing Logs on the Portal is easy. Every VM offers a Logs tab, showing all the logs. The tabs on the left allow breaking the logs down by service (starting with secretvm runtime and all the running containers), plus the "All" tabs showing all the logs in chronological order.
The logs can also be accessed through the https://<machine URL>:29343/logs endpoint
The https://<machine URL>:29343/services endpoint lists all the services running on a SecretVM, and the service name can be used on the /logs endpoint to filter the logs by a specific service, e.g.
https://<machine URL>:29343/logs?service=secretvm
See the Log Forwarding documentation to learn how to forward the SecretVM logs to a 3rd party log aggregation service
# The public hostname or IP address of your log aggregator
SECRET_VM_LFWD_HOST=your-aggregator.example.com
# The port your log aggregator is listening on
SECRET_VM_LFWD_PORT=8428# Set to 1 to enable TLS (HTTPS) for the connection.
# Default is disabled.
SECRET_VM_LFWD_TLS=1
# Specify a username for HTTP Basic Authentication.
SECRET_VM_LFWD_HTTP_USER=my-username
# Specify a password for HTTP Basic Authentication.
SECRET_VM_LFWD_HTTP_PASSWD=my-secret-password
# Modify the request URI for the log aggregator endpoint.
# This is useful if your aggregator expects a specific path.
# Default: /insert/jsonline?_stream_fields=stream&_msg_field=MESSAGE&_time_field=date
# Note: The default URI is pre-configured for compatibility with VictoriaLogs'
# JSON line ingestion format. You generally do not need to change this
# unless you are using a different aggregator with a specific endpoint requirement.
SECRET_VM_LFWD_URI=/my/custom/api/endpointOn SecretAI Portal, it is possible to stop, start, restart a SecretVM from the Machine Details page or from the list of SecretVMs:
Users can choose to delete the SecretVM. In this case, the machine's state will be lost forever.
Coming soon
SecretVMs support optional upgradeablility.
In the context of SecretVM, upgradeability means that if the workload is modified (e.g. the docker container is upgraded to a newer version), the upgraded SecretVM will get access to the encrypted state created by the previous version of the VM.
When a SecretVM is created, the developer can decide whether the VM is upgradeable or not. This decision is final and cannot be changed later in the life of SecretVM
If upgradeability is not enabled, the VM's secret keys are generated inside the KMS contract using AddSecretKeyByImage method, i.e. the keys can only be accessed by this specific VM image, and if the workload changes, the access to pre-existing secrets will be lost)
If upgradeability is enabled, the a new service is generated in the KMS contract using CreateService and AddImageToService messages. In the future, the SecretVM can be upgraded to a new workload (i.e. new set of Attestation registrs), and the new image is added to the service in the KMS contract, thus providing the upgraded VM with access to the persistence state of the previous version.
It is important that the end users are aware whether a given SecretVM is upgradeable or not. Similar to smart contracts, the users may be more willing to trust their information to non-upgradeable services. If a SecretVM is upgradeable, it is important that the users can see the upgrade history.
The upgrade history of a SecretVM is available through a dedicated endpoint built in to the that runs as part of the SecretVM Runtime.
The endpoint can be accessed using <machine url>:29343/vm_updates
If the machine is upgradeable, the endpoint will show the history of its upgrades.
Every time a new Image is added to a Service, an add_image_to_service event is published on-chain. The event has the following parameters:
service_id (ID of the Service to which a new image was aded
admin (identity of the administrator of the service)
image (a string representing the attestation fields defining the new image)
description (optional description provided by the developer)
