add config with comments for fields
Signed-off-by: Rita Zhang <rita.z.zhang@gmail.com>pull/45137/head
parent
e6aa049519
commit
4515061e7d
|
@ -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
|
||||
|
|
Loading…
Reference in New Issue