Security Audit logs not printing to console with docker

Elastic Stack Elasticsearch
1

Our ES docker container ran out of disk because of the security audit logs being written to file. I found this issue on github (https://github.com/elastic/elasticsearch-docker/issues/78) and went to verify that our docker images x-pack log4j2.properties were configured to output logs to the console and found that ours were not. I was confused by this because the github repo, at multiple versions in 5.x and 6.x show that the log4j2.properties was configured for console output. However, the docker image we were using (docker.elastic.co/elasticsearch/elasticsearch:6.0.0) was not configured to output security audit logs to the console but rather still a file. We deployed docker version of elasticsearch 6.0.0, 6.1.3, and 6.2.1 and all were configured to log security audit logs to file and not console. The only exception was the platinum edition which was configured to send audit log output to console.

the question is why does the platinum version of the docker image has the console output but the default version does not. we had to disable the logging for the time being and are hoping that the indexing doesn't loose any data.

docker.elastic.co/elasticsearch/elasticsearch:6.1.3
/usr/share/elasticsearch/config/x-pack/log4j2.properties

appender.audit_rolling.type = RollingFile
appender.audit_rolling.name = audit_rolling
appender.audit_rolling.fileName = ${sys:es.logs.base_path}${sys:file.separator}${sys:es.logs.cluster_name}_access.log
appender.audit_rolling.layout.type = PatternLayout
appender.audit_rolling.layout.pattern = [%d{ISO8601}] %m%n
appender.audit_rolling.filePattern = ${sys:es.logs.base_path}${sys:file.separator}${sys:es.logs.cluster_name}_access-%d{yyyy-MM-dd}.log
appender.audit_rolling.policies.type = Policies
appender.audit_rolling.policies.time.type = TimeBasedTriggeringPolicy
appender.audit_rolling.policies.time.interval = 1
appender.audit_rolling.policies.time.modulate = true

logger.xpack_security_audit_logfile.name = org.elasticsearch.xpack.security.audit.logfile.LoggingAuditTrail
logger.xpack_security_audit_logfile.level = info
logger.xpack_security_audit_logfile.appenderRef.audit_rolling.ref = audit_rolling
logger.xpack_security_audit_logfile.additivity = false

docker.elastic.co/elasticsearch/elasticsearch-platinum:6.1.3
/usr/share/elasticsearch/config/x-pack/log4j2.properties

logger.xpack_security_audit_logfile.name = org.elasticsearch.xpack.security.audit.logfile.LoggingAuditTrail
logger.xpack_security_audit_logfile.appenderRef.console.ref = console
logger.xpack_security_audit_logfile.level = info
2

For the moment audit logging is directed to stdout only in the "elasticsearch-platinum" containers.

Until the same configuration gets built-in to the "elasticsearch" container as well, you can use this workaround:

Create a file on the physical filesystem with the logging config that dictates sending audit logs to stdout, e.g. named stdout_log4j2.properties:

logger.xpack_security_audit_logfile.name = org.elasticsearch.xpack.security.audit.logfile.LoggingAuditTrail
logger.xpack_security_audit_logfile.appenderRef.console.ref = console
logger.xpack_security_audit_logfile.level = info

Make sure the uid/gid ownership of the file provide read permission to docker and the ES process.

Use docker's "-v" option to override the configuration file inside the container, with your file from the physical filesystem:

docker run -e ELASTIC_PASSWORD=MagicWord -v /path/to/stdout_log4j2.properties:/usr/share/elasticsearch/config/x-pack/log4j2.properties -e xpack.security.audit.enabled=true docker.elastic.co/elasticsearch/elasticsearch:6.2.2

3

Thank you for getting back to me. The original question was "why there is a difference between the images?", mostly so i can determine if we're using the wrong image or not based on if the difference was intentional or not. Is there a work item i can follow that will inform me when the configuration change gets moved into the other the other released containers?

4

The "elasticsearch" container is an alias for the "elasticsearch-basic" container which is intended for use with a basic license of X-Pack, which does not include any Security features

The "elasticsearch-platinum" container is intended to be used with a Gold or Platinum license of X-Pack which do include Security (with optional auditing)

We're in ongoing discussions about whether or not it is helpful to have that level of difference between the containers, but the reason for the difference is that they assume you will have different X-Pack features enabled.

5

With the exception of where audit logging information is output (file or console), aren't the images effectively the same once we install our own license? if so, then simply switching to the platinum edition will resolve the issue with where audit logs are output correct? in the platinum edition, do i still need to configure the auditing system to output to "file" to get audit logs output to console or will it still output to console regardless (a.k.a. how would i prevent it from logging to console)?