Authentication and authorization are two important basic requirements when setting up a production Kubernetes cluster. In this post, let's walk through some of the details that can help a Kubernetes environment plan well.
For example, you have now invoked the command to create a POD by entering the yaml file into kubectl (kubectl create -f pod.yaml). The command is sent to the secured api-server port (http://), and the authentication flow begins. Note that if you are using an insecure port (http://) for the api-server, authentication will not apply. (http://) Ideally, insecure ports (http://) should be avoided in a production environment.
The following are the authentication paths available in Kubernetes that will be mentioned in this article.
Client certificate verification
To use this scheme, api-server needs to be enabled with the -client-ca-file=<PATH_TO_CA_CERTIFICATE_FILE> option.
CA_CERTIFICATE_FILE must contain one or more certificate authorities that can be used to validate client certificates presented to the api-server. The /CN of the client certificate will be used as the username.
Token-Based Authentication
To use this scheme, the api-server needs to be enabled with the -token-auth-file=<PATH_TO_TOKEN_FILE> option. TOKEN_FILE is a csv file, each user entry has the following formats: token, user, userid, group.
The Group's name is arbitrary.
Example of token file:
A very easy way to generate tokens is to run the following command:
The challenge with token-based authentication is that the token is indefinite and any modification to the token manifest requires a restart of the api-server.
Basic Authentication
To use this scheme, the api-server needs to be enabled with the -basic-auth-file=<PATH_TO_HTTP_AUTH> option. HTTP_AUTH_FILE is a csv file, each user entry has the following format: password, user name, userid. Currently, any modification to AUTH_FILE requires restarting the api-server.
Open ID
Open ID support is also available, but in an experimental stage.
Keystone
Keystone support is also available, but in an experimental stage. If you want to integrate keystone with LDAP or Active Directory Services, then use the keystone authentication method. To use this scheme, the api-server needs to start the service with the -experimental-keystone-url=<KEYSTONE_URL> option.
After successful authentication, the next step is to find out what operations are allowed for the authenticated user. Currently, Kubernetes supports four authentication policy schemes. The api-server needs to be enabled with the -authorization-mode=<AUTHORIZATION_POLICY_NAME> option.
always deny
This policy denies all requests.
always allow
This policy allows all requests.
attribute-based access control
ABAC allows flexible user-specific authorization policies. When using the -authorization-policy-file=<PATH_TO_ABAC_POLICY_FILE> option to enable api-sever, the ABAC policy file needs to be specified. Currently, any modification to the policy file requires restarting the api-server.
A sample ABAC policy file looks like this:
In the above example, each line in the policy file is a JSON object and specifies a policy. Here is a brief description of the policy object from the Kubernetes documentation page.
Version Control Features - Allows for multiple versions and policy transformation formats.
api version, string type: A valid value is "abac.authorization.kubernetes.io/v1beta1".
kind, String type: Valid values are "policy".
Specification property - is a map with the following properties:
Object-oriented matching properties:
user, string: The user string is either from -token-auth-file or from the common name (CN) of the certificate file. If you specify a user, then it must match an authenticated user. * matches all requests.
group, string: If you specify group, it must match authenticated users in groups. * matches all requests.
resource matching properties
apiGroup, string type: API group, such as extended version. * Matches all APIgroups.
namespace, string type: namespace string. * Matches all resource requests.
Resource, string type: Resource, such as pods. * Match all resource requests.
Non-resource matching properties:
nonResourcePath, string type: matches all non-resource request paths (eg /version, /apis). * followed by matching all non-resource requests. /foo/* followed by /foo/, and its subpaths.
read-only, boolean: When true, it means that the policy should only be used for get, list and monitor operations.
Webhook
Calls up an external RESTful authorization service.
The choice of authentication and authorization mechanisms depends on your requirements. However in my experience, I have found that certificate based authentication methods, keystone based authentication methods (LDAP), authentication policy based ABAC, a flexible combination of these three methods provides the required functionality to cultivate Kubernetes environment.
To learn more about authentication and authorization, two links are recommended:
Authentication: http://kubernetes.io/docs/admin/authentication/
Authorization: http://kubernetes.io/docs/admin/authorization
Original link: http://cloudgeekz.com/1045/kubernetes-authentication-and-authorization.html#rd?sukey=3997c0719f1515203c1d484623e7ce856d8c5abebd3e3bf44f7731a8579fb1f1c4bb5e509f603c1481f702166e9e
https://my.oschina.net/caicloud/blog/701308