First, let's try to send API requests on the etcd host. You will find that anyone can access the data by default:

// Create a key-value pair in etcd
# curl -X PUT -d value="Happy coding" http://localhost:4001/v2/keys/message
{"action":"set","node":{"key":"/message","value":"Happy coding","modifiedIndex":4,"createdIndex":4}}
// Check the value you just push
# curl http://localhost:4001/v2/keys/message
{"action":"get","node":{"key":"/message","value":"Happy coding","modifiedIndex":4,"createdIndex":4}}
// Remove the value
# curl -X DELETE http://localhost:4001/v2/keys/message
{"action":"delete","node":{"key":"/message","modifiedIndex":5,"createdIndex":4},"prevNode":{"key":"/message","value":"Happy coding","modifiedIndex":4,"createdIndex":4}}

Without authentication, neither reading nor writing functions can be protected. The way to enable basic authentication of etcd is through the RESTful API as well. The procedure is as follows:

Make sure the etcd service is running. We will transfer the preceding logics into the following commands:

// Send the API request for setup root account
# curl -X PUT -d "{"user":"root","password":"<YOUR_ETCD_PASSWD>","roles":["root"]}" http://localhost:4001/v2/auth/users/root
{"user":"root","roles":["root"]}
// Enable authentication 
# curl -X PUT http://localhost:4001/v2/auth/enable
// Encode "USERACCOUNT:PASSWORD" string in base64 format, and record in a value
# AUTHSTR=$(echo -n "root:<YOUR_ETCD_PASSWD>" | base64)
// Remove all permission of guest account. Since we already enable authentication, use the authenticated root.
# curl -H "Authorization: Basic $AUTHSTR" -X PUT -d "{"role":"guest","revoke":{"kv":{"read":["*"],"write":["*"]}}}" http://localhost:4001/v2/auth/roles/guest
{"role":"guest","permissions":{"kv":{"read":[],"write":[]}}}

Now, for validation, try to check anything in etcd through the API:

# curl http://localhost:4001/v2/keys
{"message":"Insufficient credentials"}

Because we didn't specify any identity for this API call, it is regarded as a request from a guest. No authorization for even viewing data.

For long-term usage, we would put user profiles of etcd in the Kubernetes master's configuration. Check your configuration file of the Kubernetes API server. In the RHEL server, it is the file /etc/kubernetes/apiserver; or for the other Linux server, just the one for service, /etc/init.d/kubernetes-master. You can find a flag for the etcd server called --etcd-servers. Based on the previous settings, the value we attached is a simple URL with a port. It could be http://ETCD_ELB_URL:80. Add an account root and its password in a plain text format to the value, which is the authorization header for the HTTP request. The new value for flag --etcd-servers would become http://root:YOUR_ETCD_PASSWD@ETCD_ELB_URL:80. Afterwards, your Kubernetes API server daemon will work well with an authentication-enabled etcd endpoint.

Before we set up authentication in the Kubernetes master, let's check the endpoint of the master first:

# curl https://K8S_MASTER_HOST_IP:SECURED_PORT --insecure

or

# curl http://K8S_MASTER_ELB_URL:80
{
  "paths": [
    "/api",
    "/api/v1",
    "/apis",
    "/apis/extensions",
    "/apis/extensions/v1beta1",
    "/healthz",
    "/healthz/ping",
    "/logs/",
    "/metrics",
    "/resetMetrics",
    "/swagger-ui/",
    "/swaggerapi/",
    "/ui/",
    "/version"
  ]
}

We don't want the previous message to be exposed to everyone, do we? Same as the etcd host, Kubernetes master can apply basic authentication as a security mechanism. In this section, we are going to limit the permission of the API server. However, different from etcd, the information of authentication is defined in a file:

// Create a file for basic authentication with content: PASSWORD,USERNAME,UID
# cat /root/k8s-bafile
<APISERVER_BA_PASSWORD>,<APISERVER_BA_USERACCOUNT>,1

Then, we have to specify this file in the configuration file. According to your daemon management tool, the configuration file could be located at /etc/init.d/kubernetes-master or /etc/kubernetes/apiserver. A new flag named --basic-auth-file should be added to the configuration file:

Most important of all, ensure the user who starts the services of Kubernetes, either root or kubelet, has the permission to access the file you attached to the tag. After you add the new tag, it is necessary to restart the service for making the authentication effective. Next, it is good for you to try the curl command at the beginning of this section. It will return Unauthorized without providing the username and password.

Our nodes communicate with API server through the insecure port 8080. Although we didn't have to specify any role for authorizing permission, be aware of configuring the firewall of master, which only allows nodes to go through port 8080. On AWS, a security group can help for this part.

There are still some methods for the Kubernetes master's authentication. Please check the official website for other ideas (http://kubernetes.io/docs/admin/authentication/).