Merge pull request kubernetes#88 from JAORMX/audit-logs

Add audit logs to cluster-logging-log-forwarding enhancement proposal

Author: openshift-merge-robot

enhancements/cluster-logging/cluster-logging-log-forwarding.md

@@ -2,6 +2,7 @@
 title: cluster-logging-log-forwarding
 authors:
   - "@jcantrill"
+  - "@jaosorior"
 reviewers:
   - "@bparees"
   - "@ewolinetz"
@@ -63,18 +64,18 @@ It will not allow configuration of additional sources without further design con
 intended to provide a complex routing solution as one might achieve by using a custom collector configuration or a messaging solution (e.g. kafka).
 * It is not a goal for the tech-preview to support log forwarding outputs other then the ones identified for the goals. Admins can forward to their own fluentd via `forward` 
 and then configure that fluentd to forward to any number of specific logstore outputs
-
+* It is not a goal to provide secure storage for audit logs. If the deployer chooses to enable audit log forwarding, they need to make sure that the endpoint is compliant with governmental regulations and secure. The OpenShift logging Elasticsearch does not comply with those regulations.
 
 ## Proposal
 
 Log forwarding will provide a declarative way to specify the outputs for specific types of logs using a 'pipeline'.  A 'pipeline' defines simple routing for one source to one or more outputs. The source of logs are opinionated and well defined by cluster logging. The initial source types are as follows:
 
 * `logs.app` - Container logs generated by user applications running on the platform, excluding infrastructure container applications
 * `logs.infra` - Logs generated by both infrastructure components running on the platform and OKD nodes (e.g. journal logs).  "Infra" applications are defined as any pods which run in namespaces: `openshift*`, `kube*`, `default`.
+* `logs.audit` - Logs generated by the nodes' auditd (/var/log/audit/audit.log), audit logs from the kubeapi-server and the openshift-apiserver. This will not be forwarded by default.
 
 Future types may be:
 * `events.kubernetes` - Kubernetes events
-* `audit.container-engine` - Container engine audit events
 
 There are no assumptions regarding whether or not an endpoint is deployed on or off cluster.  Endpoints off-cluster may require adminstrators to perform additional actions in order for logs to be forwarded (e.g. secret creation, opening port, enable global proxy configuration) 
 Following is the list of supported endpoint types for this proposal:
@@ -92,6 +93,10 @@ This is a typical example of organizations that desires to re-use their existing
 
 This is an example of an OKD cluster hosting solution where several organizations are each provided with a dedicated cluster.  The organization requires access to application container logs but the host requires access to the infra structure logs.
 
+#### As an OKD admin, I need to forward my audit logs to a secure SIEM that meets government regulations
+
+This is often required for industries such as the US public sector, healthcare or financials. The logs will be forwarded to a government approved SIEM through secure means (mutual TLS).
+
 ### Implementation Details
 
 #### Assumptions
@@ -154,6 +159,10 @@ spec:
      source: logs.infra:
      outputRefs:
      - elasticsearch-insecure
+   - name: audit-logs
+     source: logs.audit
+     outputRefs:
+     - secureforward-offcluster
 ```
 
 The generated collector configuration is something like the following. **Note:** the source definitions from prior releases remain unchanged: