Security

Security model for Apache SkyWalking covering OAP server security, agent authentication, gRPC TLS, Elasticsearch/BanyanDB security, and inter-component encryption. See also: observability/skywalking/index, observability/skywalking/architecture, observability/skywalking/operations.

Security Architecture Overview

SkyWalking's security model spans three communication boundaries:

1. Agent to OAP: gRPC channels between language agents and the OAP server.
2. OAP to Storage: HTTP/REST connections from OAP to Elasticsearch, BanyanDB, or other storage backends.
3. User to UI: HTTP access to the SkyWalking RocketBot UI or custom dashboards.

flowchart TD
    subgraph "Application Layer"
        Java[Java Agent]
        Go[Go Agent]
        Node[Node.js Agent]
        OTel[OTLP Receivers]
    end

    subgraph "OAP Server"
        Receiver[gRPC Receivers<br/>12800 / 11800 / 4317]
        Core[OAP Core<br/>Analysis / Aggregation]
        Storage[Storage Client]
    end

    subgraph "Storage Layer"
        ES[(Elasticsearch<br/>or BanyanDB)]
    end

    subgraph "Users"
        UI[RocketBot UI<br/>8080]
    end

    Java -->|gRPC + TLS + Token| Receiver
    Go -->|gRPC + TLS + Token| Receiver
    Node -->|gRPC + TLS + Token| Receiver
    OTel -->|OTLP| Receiver
    Receiver --> Core
    Core --> Storage
    Storage -->|HTTPS + Basic Auth| ES
    UI -->|HTTP| Core

OAP Server Security

gRPC TLS Configuration

The OAP server supports TLS on all gRPC receiver ports. Configure in application.yml:

receiver-sharing-server:
  default:
    gRPCSslEnabled: true
    gRPCSslKeyPath: /etc/skywalking/certs/server.key
    gRPCSslCertChainPath: /etc/skywalking/certs/server.crt

core:
  default:
    gRPCSslEnabled: true
    gRPCSslKeyPath: /etc/skywalking/certs/server.key
    gRPCSslCertChainPath: /etc/skywalking/certs/server.crt

For mutual TLS (mTLS), configure the trusted CA certificate:

core:
  default:
    gRPCSslEnabled: true
    gRPCSslKeyPath: /etc/skywalking/certs/server.key
    gRPCSslCertChainPath: /etc/skywalking/certs/server.crt
    gRPCSslTrustedCAsPath: /etc/skywalking/certs/ca.crt

Agent Authentication (Token-Based)

SkyWalking supports token-based authentication to prevent unauthorized agents from reporting data.

OAP server configuration:

receiver-sharing-server:
  default:
    authentication: ${SW_AUTHENTICATION:"your-secret-token"}

Or via environment variable:

SW_AUTHENTICATION=your-secret-token

Agent configuration (Java):

# agent.config
agent.authentication = your-secret-token

The token is sent as gRPC metadata on every request from the agent to the OAP server. Without the correct token, the OAP server rejects the connection.

Token Management

The authentication token is a shared secret between all agents and the OAP server. Rotate it periodically and store it in a secrets management solution (Vault, Kubernetes Secrets). Avoid committing the token to version control.

Vault Integration for Token Management

Production deployments can externalize token management to HashiCorp Vault:

1. Store the token in Vault:

   vault kv put secret/skywalking agent-token="your-secret-token"
   

2. Inject the token via Kubernetes Vault Agent sidecar:

   annotations:
     vault.hashicorp.com/agent-inject: "true"
     vault.hashicorp.com/secret-path: "secret/data/skywalking"
     vault.hashicorp.com/agent-inject-template-agent-token: |
       {{ with secret "secret/data/skywalking" }}
       export SW_AGENT_AUTHENTICATION={{ .Data.data.agent-token }}
       {{ end }}
   

3. Reference via environment variable in the OAP configuration:

   authentication: ${SW_AUTHENTICATION:""}
   

Agent-to-OAP Communication Security

TLS Configuration per Agent

Java Agent:

# agent.config
agent.ssl = true
agent.ssl_cert_chain_path = /etc/skywalking/certs/ca.crt
agent.ssl_private_key_path = /etc/skywalking/certs/client.key

Go Agent:

// Configuration via environment variables
GRPC_TLS_ENABLED=true
GRPC_TLS_CERT_PATH=/etc/skywalking/certs/ca.crt

Authentication Methods

Method	Mechanism	Use Case
Shared token	gRPC metadata header	Simple deployments; single-team environments
mTLS	Client certificate verification	Multi-team; zero-trust environments
Combined	Token + mTLS	Maximum security; defense in depth

Storage Backend Security

Elasticsearch Security

SkyWalking connects to Elasticsearch via its REST API. Secure the connection with:

Authentication:

storage:
  elasticsearch7:
    nameSpace: ${SW_NAMESPACE:"skywalking"}
    clusterNodes: ${SW_STORAGE_ES_CLUSTER_NODES:"es-cluster:9200"}
    protocol: ${SW_STORAGE_ES_HTTP_PROTOCOL:"https"}
    user: ${SW_ES_USER:"skywalking"}
    password: ${SW_ES_PASSWORD:""}
    trustStorePath: ${SW_STORAGE_ES_SSL_JKS_PATH:"../es_keystore.jks"}
    trustStorePass: ${SW_STORAGE_ES_SSL_JKS_PASS:""}

Elasticsearch hardening: - Enable Elasticsearch security (xpack.security.enabled: true). - Create a dedicated skywalking user with access limited to SkyWalking indices. - Use HTTPS for all Elasticsearch connections. - Restrict Elasticsearch network access to OAP servers only.

BanyanDB Security

BanyanDB is the recommended storage backend (since SkyWalking 10). It uses gRPC for communication:

storage:
  banyandb:
    host: ${SW_STORAGE_BANYANDB_HOST:"banyandb"}
    port: ${SW_STORAGE_BANYANDB_PORT:17912}
    # TLS configuration (if enabled)
    tlsEnabled: ${SW_STORAGE_BANYANDB_TLS:false}
    tlsCertPath: ${SW_STORAGE_BANYANDB_TLS_CERT:""}

BanyanDB security considerations: - Runs as a standalone process; isolate on a private network. - No built-in authentication in the open-source version; rely on network-level access control. - Data files stored on local disk; use filesystem encryption (LUKS) for data at rest.

Data TTL and Retention

Each storage backend supports configurable data retention:

# Elasticsearch TTL configuration
recordDataTTL: ${SW_STORAGE_ES_RECORD_DATA_TTL:7}       # Days
otherMetricsDataTTL: ${SW_STORAGE_ES_OTHER_METRIC_DATA_TTL:45}  # Days
monthMetricsDataTTL: ${SW_STORAGE_ES_MONTH_METRIC_DATA_TTL:18}  # Months

• Record data (traces, logs): Short TTL (7 days) to limit storage consumption.
• Minute metrics: Medium TTL (typically 7-45 days).
• Month metrics: Long TTL (12-18 months) for long-term trend analysis.

UI Security

Network Access

The SkyWalking RocketBot UI communicates with the OAP server's REST API. Recommended deployment:

# Nginx reverse proxy for UI and API
server {
    listen 443 ssl;
    ssl_certificate /etc/nginx/certs/server.crt;
    ssl_certificate_key /etc/nginx/certs/server.key;
    ssl_protocols TLSv1.2 TLSv1.3;

    location / {
        proxy_pass http://skywalking-ui:8080;
    }
    location /graphql {
        proxy_pass http://oap:12800/graphql;
    }
}

Authentication

SkyWalking's open-source UI does not include built-in authentication. Options:

Method	Implementation
Reverse proxy auth	Nginx/Apache with Basic Auth, OAuth2 proxy, or Authelia
Service mesh	Istio/Linkerd with JWT validation at the sidecar
Cloud WAF	AWS ALB with Cognito or OIDC authentication

Inter-Component TLS

OAP Cluster Communication

When running multiple OAP nodes in a cluster, secure the internal gRPC communication:

cluster:
  standalone:
    # Or use gRPC cluster mode
  gRPC:
    host: ${SW_CLUSTER_GRPC_HOST:""}
    port: ${SW_CLUSTER_GRPC_PORT:11800}
    tlsEnabled: ${SW_CLUSTER_GRPC_TLS:false}

Envoy ALS Receiver Security

For service mesh integrations via Envoy Access Log Service (ALS):

server {
    listen 443 ssl;
    ssl_certificate /crt/server.pem;
    ssl_certificate_key /crt/server.key;
    ssl_protocols TLSv1.2 TLSv1.3;

    location /aws/firehose/metrics {
        proxy_pass http://oap:12801/aws/firehose/metrics;
    }
}

Network Security

Port	Protocol	Component	Recommended Exposure
11800	gRPC	Agent receiver (shared)	Internal; behind TLS
12800	HTTP	REST API	Behind reverse proxy
12801	HTTP	Receivers (Envoy, Firehose)	Internal only
4317	gRPC	OTLP receiver	Internal only
8080	HTTP	RocketBot UI	Behind TLS proxy
9200	HTTP	Elasticsearch	Internal only
17912	gRPC	BanyanDB	Internal only

Hardening Checklist

Area	Recommendation
Agent-to-OAP TLS	Enable gRPC TLS on all receiver ports
Agent authentication	Configure shared token; rotate periodically
Storage TLS	Use HTTPS for Elasticsearch; gRPC TLS for BanyanDB
Elasticsearch auth	Create dedicated user with index-level permissions
Network isolation	OAP and storage in private subnets
UI authentication	Deploy behind reverse proxy with SSO/OAuth2
Certificate management	Use cert-manager or Vault PKI for automated rotation
Token secrets	Store in Vault or Kubernetes secrets; never in config files
Data retention	Configure TTLs per data type to limit exposure window
Dependency updates	Keep OAP updated to address CVEs in transitive dependencies

Sources

• SkyWalking Documentation
• SkyWalking gRPC TLS
• SkyWalking Storage Setup