Enterprise Service Cloud - Docs

Use LES

Exposed Events

Types

Three types of logs are currently forwarded to the customer log stream (topic):

  • SECURITY: authentication for both successful or failed logins, and authentication processes.
  • AUDIT: actions performed in the service (e.g. create VM, stop service, day-2 operations).
  • SERVICE: events related to a specific service. For instance, firewall logs.

Cloud Services

This is an information message

Service Name Updates

On 11.01.2024, the values for the cloud_service_name key were updated. See the Cloud Service Naming Change section for the naming change mapping.

Below is the list of cloud services currently exposing their events:

Cloud Service NameDescription
Managed MS SQL DBMSAudit logs coming from MSSQL server for actions and login to the SQL. Logs covered are: AUDIT_CHANGE_GROUP, BROKER_LOGIN_GROUP, DATABASE_LOGOUT_GROUP, DATABASE_OWNERSHIP_CHANGE_GROUP, DATABASE_PERMISSION_CHANGE_GROUP, DATABASE_PRINCIPAL_CHANGE_GROUP, DATABASE_PRINCIPAL_IMPERSONATION_GROUP, DATABASE_ROLE_MEMBER_CHANGE_GROUP, FAILED_DATABASE_AUTHENTICATION_GROUP, FAILED_LOGIN_GROUP, LOGOUT_GROUP, SERVER_PERMISSION_CHANGE_GROUP, SERVER_PRINCIPAL_CHANGE_GROUP, SERVER_PRINCIPAL_IMPERSONATION_GROUP, SERVER_ROLE_MEMBER_CHANGE_GROUP, SUCCESSFUL_DATABASE_AUTHENTICATION_GROUP, SUCCESSFUL_LOGIN_GROUP, USER_DEFINED_AUDIT_GROUP
Managed Oracle DB Service RegularAudit logs from Oracle DB
Managed PostgreSQL DB ServiceAudit logs from PostgreSQL DB
Managed OS RHELAudit logs coming from operating system for action executed at operating system level. Security logs coming from operating system for any attempt to login to the system. For instance, virtual machines would publish the logs from /var/log/{secure,audit}.
Managed OS WindowsAudit logs coming from operating system for action executed at operating system level. Security logs coming from operating system for any attempt to login to the system. For example, virtual machines would publish logs from nc_winlogbeat::event_logs.
Network F5Audit logs coming from operating system for action executed at operating system level. Security logs coming from operating system for any attempt to login to the system. Logs come from files /var/log/ltm and /var/log/secure in the F5 virtual machines implementing the service.
Managed KubernetesManagement (cluster virtual machines and PKS) and authentication logs. For PKS, logs from the virtual machines are from /var/vcap/sys/logs.
File Service PremiumLogs for provision, deprovision and update events on all deployments (Catalog requests & day-2 operations).
Object Storage S3Logs for provision, deprovision and update events on S3 Instances and S3 Users.
Managed Reverse ProxyInstance proxy log messages which contain raw syslog message strings including request/response header data such as HTTP host, agent, method, path, status code and size information.
Log ExposureAudit logs for credential management actions
Health ExposureAudit logs for credential management actions

Cloud Management

The Log Exposure Service also publishes some logs from the Cloud Management Platform:

Cloud Management Service NameDescription
vRealize OrchestratorWorkflow logs for actions made by customer (e.g. deploy, reconfigure, day-2 operations). VM Lifecycle Events related with provisioning of VMs (Requested, Building machine, Activated, Disposing), VM Day-2 Operations (Reconfiguration, Power On, Power Off, Create Snapshot, Delete Snapshot), Services (Create Network, Update Network, Delete Network, Reserve IP, Free Reserved IP, Import OVA), Subtenant Lifecycle Events related with Business Groups (Create Business Groups, Update Business Groups, Delete Business Groups), OSB Services (Provision DynDB, Update DynDB, Delete DynDB, Create Kubernetes Cluster, Provision CP, Delete Dyndb, Delete CP), OSB Day-2 Operations (Start, Stop, Restart, Sync, PKS Upgrade Cluster, PKS Upgrade Persistent Storage, Create DynDB User, Delete DynDB User, PKS Bind, PKS Unbind)
vRealize AutomationSecurity logs for any login attempt on the service by the tenant.
NSX ProxyActions performed in the NSX Proxy to create firewall rules. Any GET/PUT/POST method call triggered by customer via ESC portal towards NSX Proxy.
FirewallFirewall logs that have matching firewall rules created via NSX proxy. For instance, firewall logs from matching provider/global default rules are not sent to customers.

Cloud Service Naming Change

Starting on 11.01.2024, the Swisscom cloud service names (cloud_service_name) were updated using the following mapping:

Old Service NameCurrent Cloud Service Name
eadcManaged Reverse Proxy
F5Network F5
FILESERVICEFile Service Premium
FIREWALLFirewall
KUBERNETESManaged Kubernetes
MODS-REManaged Oracle DB Service Regular
MOS-LNXManaged OS RHEL
MOS-WINManaged OS Windows
MPDSManaged PostgreSQL DB Service
MSSQLManaged MS SQL DBMS
NSXPROXYNSX Proxy
OBJECTSTORAGEObject Storage S3
VRAvRealize Automation
VROvRealize Orchestrator

Event Schema

The log events forwarded to the topic follow a schema that is described below:

FieldTypeDescription
versionstringThe version of the event schema. Fixed: 1.0
timestampstringThe UTC time of the event in ISO8601 format. Check the specific cloud service documentation about the precise semantics of this time.
idstringThe UUID of this event generated by the cloud service
tenant_namestringThe name of the tenant owning this event
cloud_service_namestringThe name of the cloud service that produced this event (see the Cloud Services and Cloud Management sections)
log_typestringOne of: SECURITY, AUDIT, SERVICE
log_entrystring or objectThe complete log entry

Example:

{
    "version": "1.0",
    "timestamp": "2023-02-14T12:40:00.000Z",
    "id": "958e11dd-a12s-425e-8738-7ba3a83958c6",
    "tenant_name": "orion-123",
    "cloud_service_name": "Managed OS RHEL",
    "log_type": "SERVICE",
    "log_entry": "a simple text log message"
}

Log Stream

┌──────────────┐                                    ┌────────────────┐
│   Service    │           logs-orion-123           │    Customer    │
│              ├──────► [ ---------------- ] ◄──────│                │
│  log events  │           (Kafka topic)            │  Kafka client  │
└──────────────┘                                    └────────────────┘

Service logs are exposed using the schema above and published to the tenant's Kafka topic. The topic name is the name of your tenant prefixed with logs-.

The customer needs to consume the log events, by configuring a Kafka consumer client on an ESC VM. A list of Kafka clients is provided in below.

Retention

The Kafka topic will retain events for at least 24 hours.

Kafka Client Configuration

When configuring the Kafka client, it is necessary to create a CA bundle containing the root certificate from the chain. Below we provide the commands to get the required certificate:

wget http://crl.swisscom.com/SwisscomRootCore.crt
openssl x509 -inform DER -in SwisscomRootCore.crt -out ca-bundle.crt

The Kafka clients must be configured with the LES Kafka endpoint which is reachable from ESC compute services (e.g. VM, K8s).

kafka.prd.msg.entcloud.swisscom.com:9094

An example of logstash is provided below:

input
{
    kafka {
        bootstrap_servers => "kafka.prd.msg.entcloud.swisscom.com:9094"
        topics => ["logs-${TENANT}"]
        group_id => "logs-${TENANT}-..."
        security_protocol => "SSL"
        ssl_truststore_location => "${TRUSTSTORE_FILENAME}"
        ssl_truststore_password => "${PASSWORD}"
        ssl_keystore_location => "${KEYSTORE_FILENAME}"
        ssl_keystore_password => "${PASSWORD}"
        ssl_key_password => "${PASSWORD}"
        codec => "json"
    }
}

If you have any problems setting up the client, please contact your Swisscom Customer Support.

List of Kafka Clients

Out of the box solutions:

For custom solutions:

Last Updated: