Unable to determine permissions for Windows Container registry edit access

Question

Having issues with a brownfield application (asp .netcore) migrating to a windows container running on mcr.microsoft.com/dotnet/core/aspnet:3.1 accessing the registry.

Specifically, I've tried to run the application and make a call and I'm getting the below:

Caught exception while emitting to sink Serilog.Core.Sinks.RestrictedSink: System.Security.SecurityException: The source was not found, but some or all event logs could not be searched.  To create the source, you need permission to read all event logs to make sure that the new source name is unique.  Inaccessible logs: Security.
   at System.Diagnostics.EventLog.FindSourceRegistration(String source, String machineName, Boolean readOnly, Boolean wantToCreate)
   at System.Diagnostics.EventLog.SourceExists(String source, String machineName, Boolean wantToCreate)
   at System.Diagnostics.EventLogInternal.VerifyAndCreateSource(String sourceName, String currentMachineName)
   at System.Diagnostics.EventLogInternal.WriteEntry(String message, EventLogEntryType type, Int32 eventID, Int16 category, Byte[] rawData)
   at System.Diagnostics.EventLog.WriteEntry(String message, EventLogEntryType type, Int32 eventID)
   at Serilog.Sinks.EventLog.EventLogSink.Emit(LogEvent logEvent)
   at Serilog.Core.Sinks.RestrictedSink.Emit(LogEvent logEvent)
   at Serilog.Core.Sinks.SafeAggregateSink.Emit(LogEvent logEvent)

Initially I thought this to be an issue with missing sources so I tried to add in some keys the existing application expects on a server through the below,

RUN cmd.exe /k REG ADD "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\eventlog\Application\blahblah.Api" 

However this did not appear to resolve the issue and I'm having a hell of a time determining how to give the appropriate permissions one would expect to req. from the initial message.

I know the application is running to a point as I've worked through remote DB connection errors and SSL request details to get to this point.

Helban

EventLogs don't make much sense in a Docker world. Have you considered switching Serilog to use a different sink? You could log to SQL Server, Seq, or any of the dozens of other available sinks? Anyways, you should show your Serilog configuration in your question. – Firstrate

@Firstrate to add some context - I'm looking at some options to migrate the brownfield as is - so I can understand what may or may not need to be changed for others or what might be out there as I'd expect this to be a common use case with apps designed outside container context. – Helban

Answer 1

An easy hack you can use is to write your logs to a source called Application which is guaranteed to exist in the machine, which is where all the common Windows logs go. That way you don't have to create a new source (and don't need special permissions). e.g.:

Log.Logger = new LoggerConfiguration()
    .WriteTo.EventLog(source: "Application")
    .CreateLogger();

Alternatively, if your app runs with admin permissions within the Docker container, you can tell Serilog to create the event log source for you by turning on manageEventSource. e.g.

Log.Logger = new LoggerConfiguration()
    .WriteTo.EventLog(/* ... */, manageEventSource: true)
    .CreateLogger();

Another alternative is to use eventcreate to create the event source for you (need to be run with admin permissions).

eventcreate /ID 1 /L APPLICATION /T INFORMATION /SO "blahblah.Api" /D "blahblah.Api"

Of course, you need to make sure that you tell Serilog to use the event log source that you created:

Log.Logger = new LoggerConfiguration()
    .WriteTo.EventLog(source: "blahblah.Api")
    .CreateLogger();

---

That said, I agree with Mason's comment above that in a Docker environment you shouldn't really be writing to the EventLog. There are better sinks available.

Rounding

thanks for the info - trying to switch to the base application is something I'll try just to see if I can get the API running. By default, would the container app run as admin? If so I'll try out code revisions for creation, but thought that may not be the case – Helban

I know creation would be a best practice, but thought still creating the source within the dockerfile might be an alternative to replicate the technical debt of it being setup manual on earlier releases. **without migrating the logging to a new method altogether – Helban