Sysdig Documentation

Set Up (Kubernetes)

Prerequisites

Overview

  • Access to a running Kubernetes cluster 1.9+

    (Note: if your environment is installed elsewhere, such as your own data center, contact Sysdig Professional Services to customize the installation instructions appropriately.)

  • Two items from your Sysdig purchase-confirmation email:

    • Your Sysdig license key

    • Your Sysdig quay.io pull secret

  • kubectl installed on your machine and communicating with the Kubernetes cluster

    (Note that your kubectl and Kubernetes versions should match to avoid errors.)

  • An External Load Balancer (required for production – see below)

    If installing in a cloud-provider environment (such as AWS, GCloud, or Azure), you will deploy an HAProxy load balancer and point a DNS record to that load balancer.

    If installing in your own data center, then you will need two DNS records, one for the collector and one for the UI.

  • A DNS server and control over a DNS name that you can point to Sysdig

Add External Load Balancer

Create a TCP load balancer (i.e., AWS NLB) that forwards ports 80, 443, 6443 to the Kubernetes worker nodes, with a healthcheck to /healthz on port 10253.

This can be done in three ways:

  1. Use an existing external load balancer. Sysdig relies heavily on DNS; you need a DNS record pointing to the load balancer.

  2. Create a load balancer in your cloud provider. (For example in AWS, see https://docs.aws.amazon.com/AmazonECS/latest/developerguide/create-network-load-balancer.html.) You need a DNS record that points to the load balancer. This is the fully qualified domain name required later in the config.yaml, api-ingress.yaml and/or api-ingress-with-secure.yaml.

  3. Create a yaml with the following content and apply it to the sysdigcloud namespace. This automatically creates a load balancer in the cloud provider environment, with an external DNS name.

    This is the fully qualified domain name required later in the config.yaml, api-ingress.yaml and/or api-ingress-with-secure.yaml.

    ---
    apiVersion: v1
    kind: Service
    metadata:
      name: haproxy-ingress-lb-service
    spec:
      type: LoadBalancer
      ports:
      - name: http
        port: 80
        targetPort: 80
      - name: https
        port: 443
        targetPort: 443
      - name: https2
        port: 6443
        targetPort: 6443
      selector:
        run: haproxy-ingress
  4. To get the DNS name, run the command:

    $ kubectl get svc -o wide -n sysdigcloud

    The output shows the External-IP (DNS name):

    NAME                         TYPE           CLUSTER-IP       EXTERNAL-IP                           PORT(S)                                        AGE       SELECTOR
    haproxy-ingress-lb-service   LoadBalancer   100.66.118.183  sample123.us-east-1.elb.amazonaws.com  80:31688/TCP,443:32324/TCP,6443:30668/TCP      1d        run=haproxy-ingress

DNS Entry (For Test Environments without Load Balancer)

Warning

Not for production environments.

Create a DNS entry for your Sysdig install using the fully qualified domain name that contains all the external IPs as A records.

This will use DNS round-robin to load balance your clients to the Kubernetes cluster.

Prepare the Environment

The install images, scripts, and other files are located in a GitHub repository: https://github.com/draios/sysdigcloud-kubernetes

Step 1 Clone the Source Files into a New Namespace

Sysdig provides the necessary scripts, images, and .yaml files in a GitHub repository. The first step is to clone those files and check out the latest version. (These examples use 1765.)

  1. Run the command:

    git clone https://github.com/draios/sysdigcloud-kubernetes.git
    cd sysdigcloud-kubernetes
    git checkout tags/v1765
  2. Create a namespace called sysdigcloud:

    kubectl create namespace sysdigcloud

Step 2 Configure Backend Components

The ConfigMap (config.yaml) is populated with information about usernames, passwords, SSL certs, and various application-specific settings.

The steps below give the minimum edits that should be performed in a test environment.

Warning

It is necessary to review and customize the entries in config.yaml before launching in a production environment.

See Making Configuration Changesfor the kubectl format to use for post-install edits, such as adding third-party authenticators like LDAP.

  1. Add your license key:

    In config.yaml, enter the key that was emailed to you in the following parameter:

    # Required: Sysdig Cloud license
      sysdigcloud.license: "
  2. Change the super admin name and password, which are the super admin credentials for the entire system. See here for details.

    Find the settings in config.yaml here:

     sysdigcloud.default.user: test@sysdig.com
      # Required: Sysdig Cloud super admin user password
      # NOTE: Change upon first login
      sysdigcloud.default.user.password: test
  3. Edit the collector endpoint and api-url:Change the defaults (sysdigcloud-collector and sysdigcloud-api:443) to point to the DNS name you have established for Sysdig.

    Note: The collector port should remain 6443.

    collector.endpoint: <DNS_NAME>
    collector.port: "6443"
    api.url: https://<DNS_NAME>:443
  4. Recommended: edit the file to set the JVM options for Cassandra, Elasticsearch, and API, worker, and collector as well.

    (To use the AWS implicit key, edit the JVM options as described in AWS: Integrate AWS Account and CloudWatch Metrics (Optional).)

    For installations over 100 agents, it is recommended to allocate 8 GB per JVM.

      cassandra.jvm.options: "-Xms8G -Xmx8G"
      elasticsearch.jvm.options: "-Xms8G -Xmx8G"
      sysdigcloud.jvm.api.options: "-Xms8G -Xmx8G"
      sysdigcloud.jvm.worker.options: "-Xms8G -Xmx8G"
      sysdigcloud.jvm.collector.options: "-Xms8G -Xmx8G"

    Note: If you do not wish to use SSL between the agent and the collector, use the following settings instead:

    cassandra.jvm.options: "-Xms8G -Xmx8G"
    elasticsearch.jvm.options: "-Xms8G -Xmx8G"
    sysdigcloud.jvm.api.options: "-Xms8G -Xmx8G -Ddraios.agents.installParams.sslEnabled=false"
    sysdigcloud.jvm.worker.options: "-Xms8G -Xmx8G -Ddraios.agents.installParams.sslEnabled=false"
    sysdigcloud.jvm.collector.options: "-Xms8G -Xmx8G -Ddraios.agents.installParams.sslEnabled=false"

    See also: Step 5 Set Up SSL Connectivity to the Backend.

  5. Deploy the configuration map and secrets for all services by running the commands:

    For Sysdig Monitor:

    kubectl -n sysdigcloud apply -f sysdigcloud/config.yaml

    To add Sysdig Secure:

    kubectl -n sysdigcloud apply -f sysdigcloud/scanning-secrets.yaml
    kubectl -n sysdigcloud apply -f sysdigcloud/anchore-secrets.yaml
  6. Configure DNS name in api-ingress.yaml (or api-ingress-with-secure.yaml if using Secure). (Files located in sysdigcloud/)

    Edit: host: <EXTERNAL-DNS-NAME> to suit your DNS name

  7. Define namespace in ingress-clusterrolebinding.yaml. (File located in sysdigcloud/ingress_controller/) Edit namespace: sysdigcloud

Step 3 (Secure-Only): Edit mysql-deployment yaml

If using Sysdig Secure :

Edit the MySQL deployment to uncomment the MYSQL_EXTRADB_* environment variables. This forces mysql to create the necessary scanning database on startup.

File location: datastores/as_kubernetes_pods/manifests/mysql/mysql-deployment.yaml

 - name: MYSQL_EXTRADB_SCANNING_DBNAME
              valueFrom:
                configMapKeyRef:
                  name: sysdigcloud-config
                  key: scanning.mysql.dbname
            - name: MYSQL_EXTRADB_SCANNING_USER
              valueFrom:
                configMapKeyRef:
                  name: sysdigcloud-config
                  key: scanning.mysql.user
            - name: MYSQL_EXTRADB_SCANNING_PASSWORD
              valueFrom:
                secretKeyRef:
                  name: sysdigcloud-scanning
                  key: scanning.mysql.password

Warning

The scanning service will not start unless MySQL creates the scanning database.

Step 4 Deploy Your Quay Pull Secret

A specific Quay pull secret is sent via email with your license key.

  1. Edit the file sysdigcloud/pull-secret.yaml and change the place holder <PULL_SECRET> with the provided pull secret.

  2. Deploy the pull secret object:

    kubectl -n sysdigcloud apply -f sysdigcloud/pull-secret.yaml

Step 5 Set Up SSL Connectivity to the Backend

SSL-secured communication is used between user browsers and the Sysdig API server(s), and between the Sysdig agent and the collectors.

To set this up, you must:

  • Use existing standard certs for API and collector, or

  • Create self-signed certificates and keys for API and collector

To disable SSL between agent and collector:

To disable SSL between agent and collectors, you set a JVM option when configuring backend components.

To create self-signed certs:

Run these commands (edit to add your API_DNS_NAME and COLLECTOR_DNS_NAME):

openssl req -new -newkey rsa:2048 -days 3650 -nodes -x509 -subj "/C=US/ST=CA/L=SanFrancisco/O=ICT/CN=<API_DNS_NAME>" -keyout server.key -out server.crt
openssl req -new -newkey rsa:2048 -days 3650 -nodes -x509 -subj "/C=US/ST=CA/L=SanFrancisco/O=ICT/CN=<COLLECTOR_DNS_NAME>" -keyout collector.key -out collector.crt

To create Kubernetes secrets:

Uses two different certificates, one for the API/UI, and one for the collector.

Run these commands:

kubectl -n sysdigcloud create secret tls sysdigcloud-ssl-secret --cert=server.crt --key=server.key
kubectl -n sysdigcloud create secret tls sysdigcloud-ssl-secret-collector --cert=collector.crt --key=collector.key

Step 6 (Optional) Use CA Certs for External SSL Connections

The Sysdig platform may sometimes open connections over SSL to certain external services, including:

  • LDAP over SSL

  • SAML over SSL

  • OpenID Connect over SSL

  • HTTPS Proxies

If the signing authorities for the certificates presented by these services are not well-known to the Sysdig Platform (e.g., if you maintain your own Certificate Authority), they are not trusted by default.

To allow the Sysdig platform to trust these certificates, use the command below to upload one or more PEM-format CA certificates. You must ensure you've uploaded all certificates in the CA approval chain to the root CA.

kubectl -n sysdigcloud create secret generic sysdigcloud-java-certs --from-file=certs1.crt --from-file=certs2.crt