Drop DynamicAuditing

The dynamic auditing feature is dropped in 1.19. Ref1: https://groups.google.com/forum/#!topic/kubernetes-sig-auth/aV_nXpa5uWU Ref2: kubernetes/kubernetes#91502
kubernetes · Jul 16, 2020 · c52731f · c52731f
1 parent c728544
commit c52731f
Show file tree

Hide file tree

Showing 2 changed files with 3 additions and 127 deletions.
diff --git a/content/en/docs/reference/command-line-tools-reference/feature-gates.md b/content/en/docs/reference/command-line-tools-reference/feature-gates.md
@@ -88,7 +88,6 @@ different Kubernetes components.
 | `DevicePlugins` | `true` | Beta | 1.10 | |
 | `DryRun` | `false` | Alpha | 1.12 | 1.12 |
 | `DryRun` | `true` | Beta | 1.13 | |
-| `DynamicAuditing` | `false` | Alpha | 1.13 | |
 | `DynamicKubeletConfig` | `false` | Alpha | 1.4 | 1.10 |
 | `DynamicKubeletConfig` | `true` | Beta | 1.11 | |
 | `EndpointSlice` | `false` | Alpha | 1.16 | 1.16 |
@@ -218,6 +217,8 @@ different Kubernetes components.
 | `CustomResourceWebhookConversion` | `false` | Alpha | 1.13 | 1.14 |
 | `CustomResourceWebhookConversion` | `true` | Beta | 1.15 | 1.15 |
 | `CustomResourceWebhookConversion` | `true` | GA | 1.16 | - |
+| `DynamicAuditing` | `false` | Alpha | 1.13 | 1.18 |
+| `DynamicAuditing` | - | Deprecated | 1.19 | - |
 | `DynamicProvisioningScheduling` | `false` | Alpha | 1.11 | 1.11 |
 | `DynamicProvisioningScheduling` | - | Deprecated| 1.12 | - |
 | `DynamicVolumeProvisioning` | `true` | Alpha | 1.3 | 1.7 |
@@ -420,7 +421,7 @@ Each feature gate is designed for enabling/disabling a specific feature:
   [default spreading](/docs/concepts/workloads/pods/pod/pod-topology-spread-constraints/#internal-default-constraints).
 - `DryRun`: Enable server-side [dry run](/docs/reference/using-api/api-concepts/#dry-run) requests
   so that validation, merging, and mutation can be tested without committing.
-- `DynamicAuditing`: Enable [dynamic auditing](/docs/tasks/debug-application-cluster/audit/#dynamic-backend)
+- `DynamicAuditing`(*deprecated*): Used to enable dynamic auditing before v1.19.
 - `DynamicKubeletConfig`: Enable the dynamic configuration of kubelet. See [Reconfigure kubelet](/docs/tasks/administer-cluster/reconfigure-kubelet/).
 - `DynamicProvisioningScheduling`: Extend the default scheduler to be aware of volume topology and handle PV provisioning.
   This feature is superseded by the `VolumeScheduling` feature completely in v1.12.

diff --git a/content/en/docs/tasks/debug-application-cluster/audit.md b/content/en/docs/tasks/debug-application-cluster/audit.md
@@ -95,7 +95,6 @@ Audit backends persist audit events to an external storage.
 
 - Log backend, which writes events to a disk
 - Webhook backend, which sends events to an external API
-- Dynamic backend, which configures webhook backends through an AuditSink API object.
 
 In all cases, audit events structure is defined by the API in the
 `audit.k8s.io` API group. The current version of the API is
@@ -147,8 +146,6 @@ audit backend using the following kube-apiserver flags:
 The webhook config file uses the kubeconfig format to specify the remote address of
 the service and credentials used to connect to it.
 
-In v1.13 webhook backends can be configured [dynamically](#dynamic-backend).
-
 ### Batching
 
 Both log and webhook backends support batching. Using webhook as an example, here's the list of
@@ -203,128 +200,6 @@ available for the log backend:
 
 By default truncate is disabled in both `webhook` and `log`, a cluster administrator should set `audit-log-truncate-enabled` or `audit-webhook-truncate-enabled` to enable the feature.
 
-### Dynamic backend
-
-{{< feature-state for_k8s_version="v1.13" state="alpha" >}}
-
-In Kubernetes version 1.13, you can configure dynamic audit webhook backends AuditSink API objects.
-
-To enable dynamic auditing 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.
-- `--runtime-config=auditregistration.k8s.io/v1alpha1=true`: enable API.
-
-When enabled, an AuditSink object can be provisioned:
-
-```yaml
-apiVersion: auditregistration.k8s.io/v1alpha1
-kind: AuditSink
-metadata:
-  name: mysink
-spec:
-  policy:
-    level: Metadata
-    stages:
-    - ResponseComplete
-  webhook:
-    throttle:
-      qps: 10
-      burst: 15
-    clientConfig:
-      url: "https://audit.app"
-```
-
-For the complete API definition, see [AuditSink](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#auditsink-v1alpha1-auditregistration). Multiple objects will exist as independent solutions.
-The name of an AuditSink object must be a valid
-[DNS subdomain name](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names).
-
-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 legacy audit 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 list of allowed stages to record.
-
-#### Contacting the webhook
-
-Once the API server has determined a request should be sent to a audit sink webhook,
-it needs to know how to contact the webhook. This is specified in the `clientConfig`
-stanza of the webhook configuration.
-
-Audit sink webhooks can either be called via a URL or a service reference,
-and can optionally include a custom CA bundle to use to verify the TLS connection.
-
-##### URL
-
-`url` gives the location of the webhook, in standard URL form
-(`scheme://host:port/path`).
-
-The `host` should not refer to a service running in the cluster; use
-a service reference by specifying the `service` field instead.
-The host might be resolved via external DNS in some apiservers
-(i.e., `kube-apiserver` cannot resolve in-cluster DNS as that would
-be a layering violation). `host` may also be an IP address.
-
-Please note that using `localhost` or `127.0.0.1` as a `host` is
-risky unless you take great care to run this webhook on all hosts
-which run an apiserver which might need to make calls to this
-webhook. Such installs are likely to be non-portable, i.e., not easy
-to turn up in a new cluster.
-
-The scheme must be "https"; the URL must begin with "https://".
-
-Attempting to use a user or basic auth (for example "user:password@") is not allowed.
-Fragments ("#...") and query parameters ("?...") are also not allowed.
-
-Here is an example of a webhook configured to call a URL
-(and expects the TLS certificate to be verified using system trust roots, so does not specify a caBundle):
-
-```yaml
-apiVersion: auditregistration.k8s.io/v1alpha1
-kind: AuditSink
-...
-spec:
-  webhook:
-    clientConfig:
-      url: "https://my-webhook.example.com:9443/my-webhook-path"
-```
-
-##### Service Reference
-
-The `service` stanza inside `clientConfig` is a reference to the service for a audit sink webhook.
-If the webhook is running within the cluster, then you should use `service` instead of `url`.
-The service namespace and name are required. The port is optional and defaults to 443.
-The path is optional and defaults to "/".
-
-Here is an example of a webhook that is configured to call a service on port "1234"
-at the subpath "/my-path", and to verify the TLS connection against the ServerName
-`my-service-name.my-service-namespace.svc` using a custom CA bundle.
-
-```yaml
-apiVersion: auditregistration.k8s.io/v1alpha1
-kind: AuditSink
-...
-spec:
-  webhook:
-    clientConfig:
-      service:
-        namespace: my-service-namespace
-        name: my-service-name
-        path: /my-path
-        port: 1234
-      caBundle: "Ci0tLS0tQk...<base64-encoded PEM bundle>...tLS0K"
-```
-
-#### 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 for a small number of sinks, and performance impact testing will be done to understand its scope before the API progresses to beta.
-
 ## Setup for multiple API servers
 
 If you're extending the Kubernetes API with the [aggregation layer][kube-aggregator], you can also