Additional notes:

*On rhel7.4 docker-1.12.6-55.gitc4618fb.el7.x86_64, the `msg.hostname` field is never set. Its value is always '?'. In both (ambiguous) occurrences.

*On fedora 26 docker-1.13.1-22.gitb5e3294.fc26.x86_64 the first `msg.hostname` field contains container id. Knowing on which container given action occurred is crucial for our cause.

Ideally we would be able to consume something like this from audit logs:
'{
  "time": "2017-09-25T06:45:23.246000+00:00",
  "systemd": {
    "t": {
      "PID": "1182",
      "UID": "0",
      "AUDIT_LOGINUID": "4294967295",
      "AUDIT_SESSION": "4294967295",
      "SELINUX_CONTEXT": "system_u:system_r:container_runtime_t:s0",
      "EXE": "\"/usr/bin/dockerd-current\""
    }
  },
  "docker": {
    "sauid": "1000",
    "container_id_short": "1235c5a6476b",
    "container_image": "centos:7",
    "pid": "10657",
    "user": "origin",
    "reason": "api",
    "operation": "resize",
    "result": "success",
    "command": "sleep"
  }
}'

Tom can you take a look at this?

I'm still looking at this, but I think this is not a RHEL Docker issue, but instead a Docker/Docker configuration issue.  I've seen this same issue on Fedora and Ubuntu.  Here's an Ubuntu snippet from audit.log:

type=PROCTITLE msg=audit(1508177281.669:88): proctitle=2F7573722F62696E2F646F636B657264002D480066643A2F2F
type=USER_END msg=audit(1508177281.733:89): pid=3962 uid=0 auid=1000 ses=1 msg='op=PAM:session_close acct="root" exe="/usr/bin/sudo" hostname=? addr=? terminal=/dev/tty1 res=success'
type=CRED_DISP msg=audit(1508177281.733:90): pid=3962 uid=0 auid=1000 ses=1 msg='op=PAM:setcred acct="root" exe="/usr/bin/sudo" hostname=? addr=? terminal=/dev/tty1 res=success'

I don't know if/how you can configure docker to make more detailed used of the audit.log, but I am going to dig further.  To date I've not had much luck finding relative information about this in the Docker documents.

This definitely is a bug - docker audit log component outputs a '?' (question mark) in stead of container ID. Thus the value of audit logs is minimal - there is no way how to tie these log messages to their origin.

I suspect this variable[0] is never set, even though docker daemon knows ID's of container it's running.

[0] https://github.com/projectatomic/docker/blob/docker-1.12.6/api/server/middleware/audit_linux.go#L279

Tom can you look at adding the container id to the audit log?

Dan, bump....to see if anyone has investigated.

I have asked Tom to look into this.  I just pinged him via email and will raise the priority.

Just a quick update.  I unfortunately had an issue with my build/test environment that took a while to fix.  I've just done so and it looks like the parsing that pulls out the containerID from the passed in URL is not working.  The container that is passed into the audit logging routine from that parsing is always nil, thus the "?".

I'm finally set to make some progress debugging, hope to have a better update tomorrow.

I found the issue.  Long story short we were initializing the pointer to the Docker daemon that the Audit logging was using after we initialized Audit logging itself.  So Audit was never able to resolve the containers.

I think most of the fields that you need are now taken care of.  If you find otherwise, please let us know.

FYI, the PR is at:  https://github.com/projectatomic/docker/pull/292.  This is aimed for Docker 1.12.6, I'll add the change to 1.13 after this one makes it's ways through the review process.

Added 3 more PRs.  Two to make the change in docker-1.13.1 and another for docker-1.13.1-rhel.  The third tweaks dockerd/daemon.go to have the audit initialization code be similar in all three versions.  No functional change for the 3rd one.

https://github.com/projectatomic/docker/pull/293
https://github.com/projectatomic/docker/pull/294
https://github.com/projectatomic/docker/pull/295

docker-latest is EOL. Closing...