Using the Tawon Operator

We will use the tawon namespace for these examples.

Create a simple Directive

Create a simple directive to see coredns traffic:

oc apply -n tawon -f ./examples/coredns.yaml

Download the example coredns.yaml.

This will create a directive that will tail the coredns logs and send the data to the nats server.

See traffic with the following command:

tawonctl utils nats sub coredns

Delete the directive with one of the following command:

oc delete -n tawon -f ./examples/coredns.yaml

Setup Topology

The TopologyAggregator CRD is used to deploy the Tawon Topology Aggregator, which is responsible for aggregating the topology information from a Topology capture Directive and make it available on the Topology API.

Create the topology capture directive with the following command:

oc apply -n tawon -f ./examples/topology.yaml

Download the example topology.yaml.

Add the topology aggregator with the following command:

oc apply -n tawon -f ./examples/topology-aggregator.yaml

Download the example topology-aggregator.yaml.

Port forward to the aggregator with the following command:

oc port-forward -n tawon svc/tawon-topology 8080:8080

You can now see the topology with the following commands:

tawonctl machines
tawonctl pods
tawonctl containers
tawonctl procs

Delete the resources with the following commands:

oc delete -n tawon -f ./examples/topology.yaml
oc delete -n tawon -f ./examples/topology-aggregator.yaml

Using the Tawon CLI

You can use the tawonctl CLI to interact with the Tawon Operator.

Note: tawonctl defaults to the tawon namespace, if you want to use a different namespace, you can use the -n flag.

Here’s some example commands:

tawonctl k8s directives
tawonctl k8s directives create -c "process.name:coredns" -t "payload"
tawonctl k8s directives sub -c "process.name:coredns" -t "payload"
tawonctl k8s directives rm directive-pxqjkgd

Referencing Secrets in Task configurations

You can reference Secrets in task configurations by referencing them in the task config.secrets array. The secret must be in the same namespace as the Directive that references it. You can then reference the secret fields in the task config with the prefix secrets.<secret-name>.<secret-field>. This will mount the secret into the container and reference the file path in the task config. This will only work for configs that are expecting a path, such as TLS configuration. Here’s an example:

    - task: publish2
      config:
        certpath: secrets.mtls.user.crt
      secrets:
        - name: mtls
          secretName: my-secret

And here’s a full example.

apiVersion: tawon.mantisnet.com/v1alpha1
kind: Directive
metadata:
  name: payload-coredns-kafka
spec:
  condition:
    equal:
      field: process.name
      value: coredns
  tasks:
    - task: capture
      config:
        filter: port 53
    - task: dns
    - task: publish2
      config:
        type: kafka
        addr: my-cluster-kafka-bootstrap.amq-streams-kafka.svc.cluster.local:9092
        topic: coredns
        certpath: secrets.mtls.user.crt
        keypath: secrets.mtls.user.key
        capath: secrets.caroot.ca.crt
      secrets:
        - name: mtls
          secretName: tawon
          namespace: openshift-operators
        - name: caroot
          secretName: my-cluster-clients-ca-cert
          namespace: openshift-operators

Quick tip: if you need to copy Secrets between namespaces, you can use the following command:

kubectl get secret my-secret -n source-namespace -o json \
  | jq 'del(.metadata["namespace","creationTimestamp","resourceVersion","selfLink","uid","ownerReferences"])' \
  | kubectl apply -n destination-namespace -f -