k8s_APIServer_access

Posted on Edited on

Introduction

Here let’s foucs on how Kubernets controll access to API server, When a request reaches the API, it goes through several stages, illustrated in the following diagram.

API Access Control

Stage of Access control

Transport security

In a typical Kubernetes cluster, the API serves on port 443, protected by TLS. The API server presents a certificate and client can present a TLS client certificate at this stage as well, but it’s an optional(verify client is not a must).

Authentication

The cluster creation script or cluster admin configures the API server to run one or more Authenticator modules.

All Kubernetes clusters have two categories of users: service accounts managed by Kubernetes, and normal users.

  • client certificates, password, and plain tokens, bootstrap tokens as normal user
  • JSON Web Tokens (used for service accounts).

To manually create a service account, use the kubectl create serviceaccount (NAME) command. This creates a service account in the current namespace and an associated secret(auto created).

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
$ kubectl create serviceaccount jenkins
$ kubectl get secret jenkins-token-1yvwg -o yaml

apiVersion: v1
kind: ServiceAccount
metadata:
  # ...
secrets:
- name: jenkins-token-1yvwg

$ kubectl get secret jenkins-token-1yvwg -o yaml

apiVersion: v1
data:
  ca.crt: (APISERVER'S CA BASE64 ENCODED)
  namespace: ZGVmYXVsdA==
  token: (BEARER TOKEN BASE64 ENCODED)
kind: Secret
metadata:
  # ...
type: kubernetes.io/service-account-token

Authorization

In Kubernetes, you must be authenticated (logged in) before your request can be authorized (granted permission to access).

It evaluates all of the request attributes against all policies and allows or denies the request. All parts of an API request must be allowed by some policy in order to proceed. This means that permissions are denied by default.

Request Attributes

  • user - The user string provided during authentication.
  • group - The list of group names to which the authenticated user belongs.
  • extra - A map of arbitrary string keys to string values, provided by the authentication layer.
  • API - Indicates whether the request is for an API resource.
  • Request path - Path to miscellaneous non-resource endpoints like /api or /healthz.
  • API request verb - API verbs like get, list, create, update, patch, watch, delete, and deletecollection are used for resource requests. To determine the request verb for a resource API endpoint, see Determine the request verb.
  • HTTP request verb - Lowercased HTTP methods like get, post, put, and delete are used for non-resource requests.
  • Resource - The ID or name of the resource that is being accessed (for resource requests only) – For resource requests using get, update, patch, and delete verbs, you must provide the resource name.
  • Subresource - The subresource that is being accessed (for resource requests only).
  • Namespace - The namespace of the object that is being accessed (for namespaced resource requests only).
  • API group - The API Group being accessed (for resource requests only). An empty string designates the core API group

Kubernetes sometimes checks authorization for additional permissions using specialized verbs.

  • RBAC
    bind and escalate verbs on roles and clusterroles resources in the rbac.authorization.k8s.io API group.
  • Authentication
    impersonate verb on users, groups, and serviceaccounts in the core API group, and the userextras in the authentication.k8s.io API group

Kubernetes supports multiple authorization modules, such as ABAC mode, RBAC Mode, and Webhook mode.

  • ABAC - Attribute-based access control (ABAC) defines an access control paradigm whereby access rights are granted to users through the use of policies which combine attributes together. The policies can use any type of attributes (user attributes, resource attributes, object, environment attributes, etc). To learn more about using the ABAC mode, see ABAC Mode

  • RBAC - Role-based access control (RBAC) is a method of regulating access to computer or network resources based on the roles of individual users within an enterprise. In this context, access is the ability of an individual user to perform a specific task, such as view, create, or modify a file. To learn more about using the RBAC mode, see RBAC Mode

When specified RBAC (Role-Based Access Control) uses the rbac.authorization.k8s.io API group to drive authorization decisions, allowing admins to dynamically configure permission policies through the Kubernetes API.

  • Webhook - A WebHook is an HTTP callback: an HTTP POST that occurs when something happens; a simple event-notification via HTTP POST. A web application implementing WebHooks will POST a message to a URL when certain things happen. To learn more about using the Webhook mode, see Webhook Mode.

Admission control

An admission controller is a piece of code that intercepts requests to the Kubernetes API server prior to persistence of the object, but after the request is authenticated and authorized.

Admission controllers may be “validating”, “mutating”, or both. Mutating controllers may modify the objects they admit; validating controllers may not.

For example.

  • EventRateLimit mitigates the problem where the API server gets flooded by event requests.

  • LimitRanger will observe the incoming request and ensure that it does not violate any of the constraints enumerated in the LimitRange object in a Namespace.

Check permission

1
2
3
4
5
# check for current user
$ kubectl auth can-i create deployments --namespace dev

# check for other user: dave
$ kubectl auth can-i list secrets --namespace dev --as dave

Ref