Shulou(Shulou.com)05/31 Report--

How to carry out K8s authentication and authorization, many novices are not very clear about this, in order to help you solve this problem, the following editor will explain for you in detail, people with this need can come to learn, I hope you can gain something.

I. Overview

Kubernetes is only responsible for managing Service accounts, not the accounts of ordinary users. Kubernetes does not have an object that represents a normal user account. Normal user information cannot be added to the cluster through API. Ordinary users are managed by external independent services. K8s uses authentication plug-in to achieve user authentication. K8s itself does not manage users and does not provide token.

II. Types of authentication supported by k8s

K8s supports X509 Client certificate, token, basic auth authentication and so on.

X509 Client Certificate:

When API Server is started, it is provided to API Server through the-- client-ca-file=SOMEFILE option.

Static token file:

1) when starting API Server, it is provided to API Server through the-- token-auth-file=SOMEFILE option.

The token file is a csv file that contains the following:

Token,user,uid, "group1,group2,group3"

2) complete authentication by providing token information in http header

Authorization: Bearer 31ada4fd-adec-460c-809a-9e56ceb75269

31ada4fd-adec-460c-809a-9e56ceb75269 is a specific token value.

Bootstrap Token

Compared to static token, this type of token can be managed dynamically.

Basic auth:

1) csv files containing password, username, uid, group and other information need to be provided to API Server through the-- basic-auth-file=SOMEFILE option and loaded when API Server starts.

2) enter the Authorization header in the header of http, which contains the Base64-encoded string of "USER:PASSWORD".

OpenID Connect Token:

Use the id_token of the OAuth3 token response (instead of access_token) as the bearer token.

You need to authenticate to the identity provider first. Then use the id_token given to you by your identity provider to access K8s. Add: Authorization: Bearer XXXXXXX to Header

To use this authentication method, you need to configure API Server:

-- URL of oidc-issuer-url IDPs, such as https://accounts.google.com, is required

-- oidc-client-id client ID, such as kubernetes, is required

For other optional parameters, see: https://kubernetes.io/docs/reference/access-authn-authz/authentication/#openid-connect-tokens

The identity provider needs to support the OpenID Connect specification.

Webhook Token Certification:

The following two parameters need to be configured in the cluster:

-- the file used by authentication-token-webhook-config-file to configure remote service (responsible for authentication)

-- authentication-token-webhook-cache-ttl is used to configure the cache time of authentication results. Default is 2 minutes.

Webhook is configured in kubeconfig file format, where clusters refers to remote service and users refers to API server webhook, as shown in the following example:

# Kubernetes API version

ApiVersion: v1

# kind of the API object

Kind: Config

# clusters refers to the remote service.

Clusters:

-name: name-of-remote-authn-service

Cluster:

Certificate-authority: / path/to/ca.pem # CA for verifying the remote service.

Server: https://authn.example.com/authenticate # URL of remote service to query. Must use 'https'.

# users refers to the API server's webhook configuration.

Users:

-name: name-of-api-server

User:

Client-certificate: / path/to/cert.pem # cert for the webhook plugin to use

Client-key: / path/to/key.pem # key matching the cert

# kubeconfig files require a context. Provide one for the API server.

Current-context: webhook

Contexts:

-context:

Cluster: name-of-remote-authn-service

User: name-of-api-sever

Name: webhook

When the client needs to authenticate the carried token, authentication webhook gives remote service POSTs an authentication.k8s.io/v1beta1 TokenReview object in JSON format, as shown in the following example:

{

"apiVersion": "authentication.k8s.io/v1beta1"

"kind": "TokenReview"

"spec": {

"token": "(BEARERTOKEN)

}

}

Remote service needs to parse the above json and verify the token, and then enter the verification result through the response. The successful response is as follows, and the http code must be 2XX:

{

"apiVersion": "authentication.k8s.io/v1beta1"

"kind": "TokenReview"

"status": {

"authenticated": true

"user": {

"username": "janedoe@example.com"

"uid": "42"

"groups": [

"developers"

"qa"

]

"extra": {

"extrafield1": [

"extravalue1"

"extravalue2"

]

}

}

}

}

Examples of failed response are as follows:

{

"apiVersion": "authentication.k8s.io/v1beta1"

"kind": "TokenReview"

"status": {

"authenticated": false

}

}

Authenticating Proxy:

The API server can recognize users, such as X-Remote-User, based on the header values configuration.

Make relevant configuration when API Service starts, indicating which key in the header of http represents the user name, which represents the user's group, and so on, as shown in the following example:

-- requestheader-username-headers=X-Remote-User

-- requestheader-group-headers=X-Remote-Group

-- requestheader-extra-headers-prefix=X-Remote-Extra-

If the request is sent as follows:

GET / HTTP/1.1

X-Remote-User: fido

X-Remote-Group: dogs

X-Remote-Group: dachshunds

X-Remote-Extra-Acme.com%2Fproject: some-project

X-Remote-Extra-Scopes: openid

X-Remote-Extra-Scopes: profile

The following user information will be generated:

Name: fido

Groups:

-dogs

-dachshunds

Extra:

Acme.com/project:

-some-project

Scopes:

-openid

-profile

To prevent header spoofing, Authenticating Proxy needs to submit a valid client certificate to the API server for authentication against the specified CA before checking the request header.

-required for requestheader-client-ca-file, certificate package for PEM-encoded. Before requesting a header for user name inspection, a valid client certificate must be presented and verified against the certification authority in the specified file.

-requestheader-allowed-names optional, (common names) Common name (cn) List. If set, the client certificate that is valid in the common name specified in the List (common names) must be submitted before checking the request header user name.

CA certificate generation script:

#! / bin/bash

Mkdir-p ssl

Cat ssl/req.cnf

[req]

Req_extensions = v3_req

Distinguished_name = req_distinguished_name

[req_distinguished_name]

[v3_req]

BasicConstraints = CA:FALSE

KeyUsage = nonRepudiation, digitalSignature, keyEncipherment

SubjectAltName = @ alt_names

[alt_names]

DNS.1 = dex.example.com

EOF

Openssl genrsa-out ssl/ca-key.pem 2048

Openssl req-x509-new-nodes-key ssl/ca-key.pem-days 10-out ssl/ca.pem-subj "/ CN=kube-ca"

Openssl genrsa-out ssl/key.pem 2048

Openssl req-new-key ssl/key.pem-out ssl/csr.pem-subj "/ CN=kube-ca"-config ssl/req.cnf

Openssl x509-req-in ssl/csr.pem-CA ssl/ca.pem-CAkey ssl/ca-key.pem-CAcreateserial-out ssl/cert.pem-days 10-extensions v3_req-extfile ssl/req.cnf

III. K8s two-way authentication

When k8s mutual authentication, O = {group}, CN= {username} of client certificate

In webhook mode, K8s receives client-side certificate resolution group and username, and interacts with the webhook plug-in to authenticate users and permissions

Client kubeconfig only needs to configure client certificate and private key file under users:

Client-certificate

Client-key

Embed-certs=true

Note: when accessing CISM, fill in group and username, select CA root certificate file, VNFM server automatically generates client certificate and secret key file, and dynamically modify kubeconfig configuration file.

Or select the client certificate directly. In this scenario, you need to determine the user name and the corresponding group used by VNFM in advance, and create the client certificate first. It is recommended to use this method. Users are not required to fill in group and username on the interface

Webhook token Certification:

Get token from components of webhook

Bring to k8s in header

K8s and webhook communicate to authenticate token

Webhook returns the authentication result (user name, group, additional information)

Server-- authentication-token-webhook-config-file and-- authentication-token-webhook-cache-ttl

# Kubernetes API version

ApiVersion: v1

# kind of the API object

Kind: Config

# clusters refers to the remote service.

Clusters:

-name: name-of-remote-authn-service

Cluster:

Certificate-authority: / path/to/ca.pem # CA for verifying the remote service.

Server: https://authn.example.com/authenticate # URL of remote service to query. Must use 'https'.

# users refers to the API server's webhook configuration.

Users:

-name: name-of-api-server

User:

Client-certificate: / path/to/cert.pem # cert for the webhook plugin to use

Client-key: / path/to/key.pem # key matching the cert

# kubeconfig files require a context. Provide one for the API server.

Current-context: webhook

Contexts:

-context:

Cluster: name-of-remote-authn-service

User: name-of-api-sever

Name: webhook

Webhook Licensing:

Server is enabled-authorization-webhook-config-file

# Kubernetes API version

ApiVersion: v1

# kind of the API object

Kind: Config

# clusters refers to the remote service.

Clusters:

-name: name-of-remote-authz-service

Cluster:

# CA for verifying the remote service.

Certificate-authority: / path/to/ca.pem

# URL of remote service to query. Must use 'https'. May not include parameters.

Server: https://authz.example.com/authorize

# users refers to the API Server's webhook configuration.

Users:

-name: name-of-api-server

User:

Client-certificate: / path/to/cert.pem # cert for the webhook plugin to use

Client-key: / path/to/key.pem # key matching the cert

# kubeconfig files require a context. Provide one for the API Server.

Current-context: webhook

Contexts:

-context:

Cluster: name-of-remote-authz-service

User: name-of-api-server

Name: webhook

Two-way authentication and token can coexist, as follows:

User defines the client credentials used to authenticate to the kubernetes cluster.

The available credentials are client-certificate, client-key, token and username/password, and embed-certs.

Username/password and token can only be chosen, but client-certificate and client-key can be combined with them respectively.

You can use kubectl config set-credentials to add or modify user entries.

-- embed-certs=true: embeds the ca.pem and admin.pem certificate contents into the generated kubectl.kubeconfig file (without adding time, the certificate file path is written)

When accessing k8s in helm mode, if you want to support token, you need to set token in kubeconfig, and if token is dynamically acquired, you need to modify the kubeconfig file regularly.

Kubeconfig example:

ApiVersion: v1

Clusters:

-cluster:

Certificate-authority: fake-ca-file

Server: https://1.2.3.4

Name: development

-cluster:

Insecure-skip-tls-verify: true

Server: https://5.6.7.8

Name: scratch

Contexts:

-context:

Cluster: development

Namespace: frontend

User: developer

Name: dev-frontend

-context:

Cluster: development

Namespace: storage

User: developer

Name: dev-storage

-context:

Cluster: scratch

Namespace: default

User: experimenter

Name: exp-scratch

Current-context: ""

Kind: Config

Preferences: {}

Users:

-name: developer

User:

Client-certificate: fake-cert-file

Client-key: fake-key-file

-name: experimenter

User:

Password: some-password

Username: exp

Where certificate-authority, client-certificate, and client-key are the paths to the certificate and key files. If you use BASE64 to encrypt the data, you need to use the following instead:

Certificate-authority-data, client-certificate-data, client-key-data

Is it helpful for you to read the above content? If you want to know more about the relevant knowledge or read more related articles, please follow the industry information channel, thank you for your support.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.