Why istio's mixer logs are working differently for my case?

10/2/2019

I have a DB in namespace ns-restriction-demo-2 and a nodeJs application that is using that DB from namespace ns-restriction-demo-1. So I was trying to add authorization i.e. DB can only be access by one namespace (ns-restriction-demo-1), but when I enable the mixer logs, I realise that the source attributes are different.

{
  "level": "warn",
  "time": "0001-01-01T00:00:00.000000Z",
  "instance": "newlog.instance.ns-restriction-demo-2",
  "destination": "db-demo-2",
  "destinationName": "db-demo-2-868c4bb6c7-f5l7c",
  "destinationNamespace": "ns-restriction-demo-2",
  "destinationPort": 3306,
  "destinationPrinciple": "unkown",
  "latency": "0s",
  "mtls": false,
  "requestHost": "unkown",
  "responseCode": 0,
  "responseSize": 0,
  "source": "calico-node",
  "sourceName": "calico-node-ljzxl",
  "sourceNamespace": "kube-system",
  "sourcePrinicple": "unkown",
  "sourceServiceAccount": "calico-node",
  "sourceservices": "unkown",
  "user": "unknown"
}

Configuration I have used

apiVersion: config.istio.io/v1alpha2
kind: instance
metadata:
  name: newlog
  namespace: ns-restriction-demo-2
spec:
  compiledTemplate: logentry
  params:
    severity: '"warning"'
    variables:
      sourceName: source.name | "unkown"
      sourceNamespace: source.namespace | "unkown"
      sourcePrinicple: source.principal | "unkown"
      sourceServiceAccount: source.serviceAccount | "unkown"
      sourceservices: source.services | "unkown"
      destinationPort: destination.port | 0
      destinationName: destination.name | "unkown"
      destinationNamespace: destination.namespace | "unkown"
      destinationPrinciple: destination.principal | "unkown"
      requestHost: request.host | "unkown"
      source: source.labels["app"] | source.workload.name | "unknown"
      user: source.user | "unknown"
      mtls: connection.mtls | false
      destination: destination.labels["app"] | destination.workload.name | "unknown"
      responseCode: response.code | 0
      responseSize: response.size | 0
      latency: response.duration | "0ms"
    monitored_resource_type: '"UNSPECIFIED"'
---
# Configuration for a stdio handler
apiVersion: config.istio.io/v1alpha2
kind: handler
metadata:
  name: newloghandler
  namespace: ns-restriction-demo-2
spec:
  compiledAdapter: stdio
  params:
    severity_levels:
      warning: 1 # Params.Level.WARNING
    outputAsJson: true
---
# Rule to send logentry instances to a stdio handler
apiVersion: config.istio.io/v1alpha2
kind: rule
metadata:
  name: newlogstdio
  namespace: ns-restriction-demo-2
spec:
  match: "true" # match for all requests
  actions:
   - handler: newloghandler
     instances:
     - newlog
---

So I have a question for the istio's expert here. Why source or sourceName or sourceNamespace is related to calico? why is it not about that nodeJs app that is using this DB?

Please help me understand what have I done wrong or missing something?

Calico Version

Client Version:    v3.5.8
Git commit:        107e128
Cluster Version:   v3.6.2
Cluster Type:      k8s,bgp,kdd

Other Versions

  • Istio: 1.1.10
  • Kubernetes: 1.13.6
-- Waqar Ahmed
istio
kubernetes

1 Answer

10/16/2019

Collecting metrics with Mixer for TCP Services is different from the HTTP one.

The access to your database is an example of TCP workload inside Istio Mesh.

Therefore please use a dedicated 'tcpaccesslog' template instead of 'logentry' one, which includes in attributes mapping a valid protocol configuration:

'protocol: context.protocol | "tcp"'

This helps Istio to properly derive source and sourceName attributes.

Note: in case a requests to DB are sent over mTLS enabled TCP connection, you should have available some extra attributes:

  • source.workload.name
  • source.workload.namespace
-- Nepomucen
Source: StackOverflow