add config with comments for fields

Signed-off-by: Rita Zhang <rita.z.zhang@gmail.com>
pull/45137/head
Rita Zhang 2024-03-25 12:21:22 -07:00
parent e6aa049519
commit 4515061e7d
No known key found for this signature in database
GPG Key ID: 3ADE11B31515DF8C
1 changed files with 108 additions and 8 deletions

View File

@ -51,9 +51,110 @@ opens up new possibilities for securing and managing Kubernetes clusters more
effectively. effectively.
## Sample Configurations ## Sample Configurations
These configuration examples illustrate real world scenarios that need the Here is a sample structured authorization configuration along with descriptions
ability to specify multiple webhooks with distinct settings, precedence order, for all fields, their defaults, and possible values.
and failure modes.
```yaml
apiVersion: apiserver.config.k8s.io/v1beta1
kind: AuthorizationConfiguration
authorizers:
- type: Webhook
# Name used to describe the authorizer
# This is explicitly used in monitoring machinery for metrics
# Note:
# - Validation for this field is similar to how K8s labels are validated today.
# Required, with no default
name: webhook
webhook:
# The duration to cache 'authorized' responses from the webhook
# authorizer.
# Same as setting `--authorization-webhook-cache-authorized-ttl` flag
# Default: 5m0s
authorizedTTL: 30s
# The duration to cache 'unauthorized' responses from the webhook
# authorizer.
# Same as setting `--authorization-webhook-cache-unauthorized-ttl` flag
# Default: 30s
unauthorizedTTL: 30s
# Timeout for the webhook request
# Maximum allowed is 30s.
# Required, with no default.
timeout: 3s
# The API version of the authorization.k8s.io SubjectAccessReview to
# send to and expect from the webhook.
# Same as setting `--authorization-webhook-version` flag
# Required, with no default
# Valid values: v1beta1, v1
subjectAccessReviewVersion: v1
# MatchConditionSubjectAccessReviewVersion specifies the SubjectAccessReview
# version the CEL expressions are evaluated against
# Valid values: v1
# Required, no default value
matchConditionSubjectAccessReviewVersion: v1
# Controls the authorization decision when a webhook request fails to
# complete or returns a malformed response or errors evaluating
# matchConditions.
# Valid values:
# - NoOpinion: continue to subsequent authorizers to see if one of
# them allows the request
# - Deny: reject the request without consulting subsequent authorizers
# Required, with no default.
failurePolicy: Deny
connectionInfo:
# Controls how the webhook should communicate with the server.
# Valid values:
# - KubeConfig: use the file specified in kubeConfigFile to locate the
# server.
# - InClusterConfig: use the in-cluster configuration to call the
# SubjectAccessReview API hosted by kube-apiserver. This mode is not
# allowed for kube-apiserver.
type: KubeConfig
# Path to KubeConfigFile for connection info
# Required, if connectionInfo.Type is KubeConfig
kubeConfigFile: /kube-system-authz-webhook.yaml
# matchConditions is a list of conditions that must be met for a request to be sent to this
# webhook. An empty list of matchConditions matches all requests.
# There are a maximum of 64 match conditions allowed.
#
# The exact matching logic is (in order):
# 1. If at least one matchCondition evaluates to FALSE, then the webhook is skipped.
# 2. If ALL matchConditions evaluate to TRUE, then the webhook is called.
# 3. If at least one matchCondition evaluates to an error (but none are FALSE):
# - If failurePolicy=Deny, then the webhook rejects the request
# - If failurePolicy=NoOpinion, then the error is ignored and the webhook is skipped
matchConditions:
# expression represents the expression which will be evaluated by CEL. Must evaluate to bool.
# CEL expressions have access to the contents of the SubjectAccessReview in v1 version.
# If version specified by subjectAccessReviewVersion in the request variable is v1beta1,
# the contents would be converted to the v1 version before evaluating the CEL expression.
#
# Documentation on CEL: https://kubernetes.io/docs/reference/using-api/cel/
#
# only send resource requests to the webhook
- expression: has(request.resourceAttributes)
# only intercept requests to kube-system
- expression: request.resourceAttributes.namespace == 'kube-system'
# don't intercept requests from kube-system service accounts
- expression: !('system:serviceaccounts:kube-system' in request.user.groups)
- type: Node
name: node
- type: RBAC
name: rbac
- type: Webhook
name: in-cluster-authorizer
webhook:
authorizedTTL: 5m
unauthorizedTTL: 30s
timeout: 3s
subjectAccessReviewVersion: v1
failurePolicy: NoOpinion
connectionInfo:
type: InClusterConfig
```
The following configuration examples illustrate real world scenarios that need
the ability to specify multiple webhooks with distinct settings, precedence
order, and failure modes.
### Protecting Installed CRDs ### Protecting Installed CRDs
Ensuring the availability of Custom Resource Definitions (CRDs) at cluster Ensuring the availability of Custom Resource Definitions (CRDs) at cluster
@ -173,14 +274,13 @@ those will continue to work as-is.
The following kind Cluster configuration sets that command argument on the The following kind Cluster configuration sets that command argument on the
APIserver to load an AuthorizationConfiguration from a file APIserver to load an AuthorizationConfiguration from a file
(`authorization_config.yaml`) in the files folder. (`authorization_config.yaml`) in the files folder. Any needed kubeconfig and
Any needed kubeconfig and certificate files can also be put in the files certificate files can also be put in the files directory.
directory.
```yaml ```yaml
kind: Cluster kind: Cluster
apiVersion: kind.x-k8s.io/v1alpha4 apiVersion: kind.x-k8s.io/v1alpha4
featureGates: featureGates:
StructuredAuthorizationConfiguration: true # enabled by default in v1.30 StructuredAuthorizationConfiguration: true # only required for v1.29; enabled by default in v1.30
kubeadmConfigPatches: kubeadmConfigPatches:
- | - |
kind: ClusterConfiguration kind: ClusterConfiguration