Use Event Exposure (common)

Contributing Services

Cloud Services

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

Cloud Service Name	Health Events	Log Events
File Service Premium	-	Logs for provision, deprovision and update events on all deployments (Catalog requests & day-2 operations).
Managed Kubernetes	-	Management (cluster virtual machines and PKS) and authentication logs. For PKS, logs from the virtual machines are from /var/vcap/sys/logs.
Managed MS SQL DBMS	-	Audit 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 Highend	-	Audit logs from Oracle DB.
Managed Oracle DB Service Regular	-	Audit logs from Oracle DB.
Managed Oracle DB Service on ExaCC	-	-
Managed OS RHEL	-	Audit 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 the logs from /var/log/{secure,audit}.
Managed OS Windows	-	Audit 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 F5	-	Audit 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.
Network Services	YES	Instance 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.
Network Uplink	YES	-
Object Storage S3	-	Logs for provision, deprovision and update events on S3 Instances and S3 Users.
Virtual Machine	YES	-
Log Exposure	YES	Audit logs for credential management actions.
Health Exposure	YES	Audit logs for credential management actions.

Cloud Management

Some Cloud Management Platform components expose their events too:

Cloud Management Service Name	Health Events	Log Events
Firewall	-	Firewall 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.
Infrastructure as a Service	-	Audit logs for infrastructure changes
NSX Proxy	-	Actions performed in the NSX Proxy to create firewall rules. Any GET/PUT/POST method call triggered by customer via ESC portal towards NSX Proxy.
Swisscom Cloud Orchestrator	-	Audit logs for space-related operations.
vRealize Automation	-	Security logs for any login attempt on the service by the tenant.
vRealize Orchestrator	-	Workflow 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).

Service Instance Classes

Some services may be built up with multiple types of resources, which are organized into separate instance classes. This detail is available from event schema 1.1.

Cloud Service Name	Instance Class Names
File Service Premium	File System Service, Container, Share, Initiator, Initiator Group, File System Service for Kubernetes, Storage Virtual Machine for Kubernetes
Managed Kubernetes	Kubernetes Cluster, Kubernetes Environment
Managed Oracle DB Service Highend	MODS Highend CDB, MODS Highend PDB
Managed Oracle DB Service Regular	MODS Regular CDB, MODS Regular PDB
Managed Oracle DB Service on ExaCC	MODS ExaCC CDB, MODS ExaCC VM
Managed OS RHEL	Managed RHEL
Managed OS Windows	Managed Windows
Network F5	F5 Load Balancer
Network Services	Managed Forward Proxy, Managed Reverse Proxy
Network Uplink	Uplink Topology
Object Storage S3	Object Storage S3, NAT Network
Virtual Machine	Virtual Machine, Snapshot, Network, Uplink Topology
Log Exposure	Log Exposure Endpoint
Health Exposure	Health Exposure Endpoint
Infrastructure as a Service	Cloud Management Platform
Swisscom Cloud Orchestrator	Cloud Management Platform, Space

Consuming Events

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

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

The Event Exposure Kafka endpoints are using a child certificate of the Swisscom RootCore CA. 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

This is an information message

Please Note

The server certificates of Event Exposure Kafka brokers are rotated automatically every few months. To avoid issues when this happens, trust only the root certificate, not the whole chain reported by the brokers.

An example Logstash configuration looks like this:

input
{
    kafka {
        bootstrap_servers => "kafka.prd.msg.entcloud.swisscom.com:9094"
        topics => ["logs-orion-123"]
        group_id => "the-consumer-group-set-at-certificate-creation"
        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 ESC support.

List of Kafka Clients

Out of the box solutions:

• Logstash Kafka input plugin (documentation)
• InfluxDB and Kafka (blog entry)

For custom solutions:

• Apache Kafka Clients