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.
## Sample Configurations
These configuration examples illustrate real world scenarios that need the
ability to specify multiple webhooks with distinct settings, precedence order,
and failure modes.
Here is a sample structured authorization configuration along with descriptions
for all fields, their defaults, and possible values.
```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
Ensuring the availability of Custom Resource Definitions (CRDs) at cluster
@ -171,16 +272,15 @@ argument. From Kubernetes 1.30, the feature is in beta and enabled by default.
If you want to keep using command line flags instead of a configuration file,
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
(`authorization_config.yaml`) in the files folder.
Any needed kubeconfig and certificate files can also be put in the files
directory.
(`authorization_config.yaml`) in the files folder. Any needed kubeconfig and
certificate files can also be put in the files directory.
```yaml
kind: Cluster
apiVersion: kind.x-k8s.io/v1alpha4
featureGates:
StructuredAuthorizationConfiguration: true # enabled by default in v1.30
StructuredAuthorizationConfiguration: true # only required for v1.29; enabled by default in v1.30
kubeadmConfigPatches:
- |
kind: ClusterConfiguration