Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support Windows container FluentD querying Windows event logs #65

Open
inosvaruag opened this issue Aug 31, 2020 · 9 comments
Open

Support Windows container FluentD querying Windows event logs #65

inosvaruag opened this issue Aug 31, 2020 · 9 comments
Labels
enhancement in_windows_eventlog2(new) For new in_windows_eventlog2 plugin issue

Comments

@inosvaruag
Copy link

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
Copy link
Contributor

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

This comment has been minimized.

@cosmo0920
Copy link
Contributor

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
Copy link
Author

inosvaruag commented Sep 8, 2020

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
Copy link
Contributor

cosmo0920 commented Sep 11, 2020

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
Copy link
Author

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
Copy link
Contributor

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

@cosmo0920
Copy link
Contributor

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

@canob
Copy link

canob commented Nov 16, 2023

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement in_windows_eventlog2(new) For new in_windows_eventlog2 plugin issue
Projects
None yet
Development

No branches or pull requests

3 participants