dynamic audit documentation

content/en/docs/tasks/debug-application-cluster/audit.md

@@ -207,6 +207,59 @@ same format as described above to the aggregated apiserver and set up the log in
 to pick up audit logs. Different apiservers can have different audit configurations and different
 audit policies.
 
+## Dynamic Auditing
+
+{{< feature-state for_k8s_version="v1.13" state="alpha" >}}
+
+In Kubeernetes version 1.13, you can configure dynamic audit webhook backends  AuditSink API objects. 
+
+To enable dynamic auditingm you must set the following apiserver flags:
+
+- `--audit-dynamic-configuration`: the primary switch. When the feature is at GA, the only required flag.
+- `--feature-gates=DynamicAuditing=true`: feature gate at alpha and beta.
+
+When enabled, an AuditSink object can be provisioned:
+
+```yaml
+apiVersion: auditregistration.k8s.io/v1alpha1
+kind: AuditSink
+metadata:
+  name: <name>
+spec:
+  policy:
+    level: <level>
+    stages:
+    - <stage>
+  webhook:
+    throttle:
+      qps: <10>
+      burst: <15>
+    clientConfig:
+      url: <backend url>
+      service:
+        name: <service name>
+        namespace: <service namespace>
+      caBundle: <ca bundle>
+```
+
+For the complete API definition, see [the godoc](https://github.com/kubernetes/kubernetes/blob/master/staging/src/k8s.io/apiserver/pkg/apis/audit/v1alpha1/types.go). Multiple objects will exist as independent solutions.
+
+Existing static backends that you configure with runtime flags are not affected by this feature. However, the dynamic backends share the truncate options of the static webhook. If webhook truncate options are set with runtime flags, they are applied to all dynamic backends.
+
+### Policy
+
+The AuditSink policy differs from the runtime policy. This is because the API object serves different use cases. The policy will continue to evolve to serve more use cases.
+
+The `level` field applies the given audit level to all requests. The `stages` field is now a whitelist of stages to record.
+
+### Security
+
+Administrators should be aware that allowing write access to this feature grants read access to all cluster data. Access should be treated as a `cluster-admin` level privilege.
+
+### Performance
+
+Currently, this feature has performance implications for the apiserver in the form of increased cpu and memory usage. This should be nominal, and performance impact testing will be done to understand its scope before the API progresses to beta.
+
 ## Log Collector Examples
 
 ### Use fluentd to collect and distribute audit events from log file