Debug authentication issues by using Pod logs

Cluster administrators and developers can debug problems and monitor cluster activity by using the logs of the system Pods that handle authentication from third-party providers. This document applies only to supported cluster types that are registered to a fleet.

Based on the severity of the problem, logs are classified using the following severity levels:

  • INFO[I]: An operational event with high-level details of the actions taken by the application during the processing of requests (such as startup and housekeeping messages). The logs also contain information about expected events that could result in problems. Examples include authentication and workflow checks.
  • WARNING[W]: An unexpected event that may indicate an underlying problem. Examples include provider-specific authentication issues.
  • ERROR[E]: An unexpected problematic event that requires a cluster administrator to fix the issue. Examples include missing configuration, token exchange failure, and authentication issues.

The following is an example of a typical pod log message:

I0926 09:00:00.000000 12345 foo.cc:10] Skipping Kubernetes Webhook adapter startup since it is not configured.

where,

  • The prefix I represents the INFO severity level, appended with the log date 0926.
  • The time follows, with microseconds, in the machine's local timezone.
  • 12345 is a thread ID number.
  • foo.cc:10 is the source code location where the log description appears (the bracket [ and space are fixed delimiters before the message).

To learn more about logging and cluster administration, see Cluster administration.