Support Windows container FluentD querying Windows event logs

[inosvaruag]

Is your feature request related to a problem? Please describe.

FluentD can run within a container on Windows. But when running in this mode, this plugin cannot get the underlying VM's Windows event logs.

Describe the solution you'd like

Allow this plugin to capture Windows event logs when running inside a Windows container. Remote event log access, WMI Remoting, Powershell remoting, CIM sessions, etc. could be used for establishing this connection.

Describe alternatives you've considered

There is no way of running this plugin to get underlying VM's event logs from within a container. Only option is to run as a service on Windows outside of a container.

[cosmo0920]

Currently, fluent-plugin-windows-eventlog's in_windows_eventlog2 does not provide remote accessing feature.
This requires to create Ruby binding for EvtOpenSession and remote session handling on EvtOpenPublisherMetadata.
The Ruby binding is developing on https://github.com/fluent-plugins-nursery/winevt_c.

[cosmo0920]

Currently, I'm developing remoting access in the following branch:
https://github.com/fluent-plugins-nursery/winevt_c/tree/remoting-access

But I'm not sure Windows conatiner to be able to login with NTLM authentication.
Could you explain how to access with Windows docker containers?
WMI remoting, Powershell remoting, CIM sessions NTLM authentication are possible to establish connections between Windows container host and its clients which are also called as Windows docker containers, @inosvaruag?

[cosmo0920]

There is no way of running this plugin to get underlying VM's event logs from within a container.

Ah, I got it.
Inside docker container, there is no way to access host's Windows EventLog.
Yeah, I'm implementing remoting access functionality in https://github.com/fluent-plugins-nursery/winevt_c/tree/remoting-access.

[inosvaruag]

Great! Yes, this would require some form of remote access with credentials to the host VM. And also opening up network and firewall access.

My vote is to start with approach 2 - it should work for most scenarios and has lower security surface area than approach 1. Eventually, approach 3 should be considered to make management easier for large enterprise deployments.

Approach 1: WinRM based remoting e.g. Powershell remoting

• Requires administrator credentials on the host VM to be passed to plugin
• Requires WinRM port to be opened up

Approach 2: Eventlog remoting

• Requires event log viewer or higher credential for the host VM to be passed to plugin
• Requires Windows firewall rules for Remote event log access to be opened up

Approach 3: gMSA (Group managed service account) accounts

• This only works for host VMs which are part of Active Directory domain (that's ~all enterprises).
• gMSA account with event viewer or higher access needs to be configured on the host VM. Containers automatically get the credentials.
• The gMSA credentials can be used to facilitate either approach 1 or 2.

I'm new to Ruby so lack in-depth knowledge on how to develop this but I'm happy to help for any Windows related questions to make this work. I have built working prototypes for some these approaches in other languages.

[cosmo0920]

I think that approach 2 is better.

<winevt.h> supports remoting session:
https://docs.microsoft.com/ja-jp/windows/win32/api/winevt/nf-winevt-evtopensession

I'm confirming for EvtRpcLoginAuthDefault which means doing Negotiate by default flag to authenticate remote Windows 10 box which uses cp932 code page.
fluent-plugins-nursery/winevt_c#30 (comment)

I'm not sure gMSA accounts but EvtRpcLoginAuthKerberos on EvtOpenSession might handle kerberos authentication method.

[inosvaruag]

Using Negotiate is better. It automatically does NTLM or Kerberos authentication depending on what the client supports.

About gMSA:

In approach 2, FluentD accepts username and password for authentication. The disadvantage is higher operations workload - the administrator has to create, distribute, and manage password rotation of user account to all VMs.

In approach 3, administration is easier. Container automatically runs as gMSA account and doesn't require username and password. This is very easy to administer.

I agree that we should first get approach 2 working.

[cosmo0920]

I’d created a PR to support remoting access for Windows EventLog:
#66

[cosmo0920]

I’d published Approach 2: Eventlog remoting approach functionality as v0.8.0.
Could you try it out?

[canob]

Hi @cosmo0920 , how are you?
I see that this is an old issue, but I can confirm you that using fluent/fluentd:v1.16.3-windows-ltsc2022-1.0 docker image, with some additional gems added in the Dockerfile (fluent-plugin-windows-eventlog, fluent-plugin-parser-winevt_xml and nokogiri), I'm collecting the logs of a remote Domain Controller from a Fluentd that is inside a Windows Docker Container in other server.