Update controlling-access.md
This commit is contained in:
@@ -130,6 +130,16 @@ Once a request passes all admission controllers, it is validated using the valid
|
||||
for the corresponding API object, and then written to the object store (shown as step **4**).
|
||||
|
||||
|
||||
## Auditing
|
||||
|
||||
Kubernetes auditing provides a security-relevant, chronological set of records documenting the sequence of actions in a cluster.
|
||||
The cluster audits the activities generated by users, by applications that use the Kubernetes API, and by the control plane itself.
|
||||
Each request on each stage of its execution generates an audit event, which is then pre-processed according to a certain policy and written to a backend.
|
||||
The policy determines what's recorded when an event is processed and it's compared against the list of rules in order. The first matching rule sets the audit level of the event.
|
||||
The defined audit levels are: None, Metadata, Request and RequestResponse.
|
||||
The Audit backends persist audit events to an external storage. By default kube-apiserver provides two backends: log and webhook backend.
|
||||
|
||||
|
||||
## API server ports and IPs
|
||||
|
||||
The previous discussion applies to requests sent to the secure port of the API server
|
||||
|
||||
Reference in New Issue
Block a user