Access to multiple servers

https://kubernetes.io/docs/tasks/access-application-cluster/configure-access-multiple-clusters/

• You can quickly switch between clusters by using the kubectl config use-context command. or kubectl config --kubeconfig=config-demo use-context dev-frontend
• Each context is a triple (cluster, user, namespace).

Commands

• To view config kubectl config view or kubectl config --kubeconfig=config-demo view
• To just view current cotext kubectl config view --minify or kubectl config --kubeconfig=config-demo view --minify
• Using multiple kube configs export KUBECONFIG=$KUBECONFIG:config-demo:config-demo-2

Authentication

https://kubernetes.io/docs/reference/access-authn-authz/authentication/

All Kubernetes clusters have two categories of users:

1. service accounts managed by Kubernetes
2. normal users.

It is assumed that a cluster-independent service manages normal users in the following ways:

• an administrator distributing private keys
• a user store like Keystone or Google Accounts
• a file with a list of usernames and passwords

Normal Users

Kubernetes does not have objects which represent normal user accounts. Normal users cannot be added to a cluster through an API call.

Even though a normal user cannot be added via an API call, any user that presents a valid certificate signed by the cluster's certificate authority (CA) is considered authenticated.

In this configuration, Kubernetes determines the username from the common name field in the 'subject' of the cert (e.g., "/CN=bob"). From there, the role based access control (RBAC) sub-system would determine whether the user is authorized to perform a specific operation on a resource

Service Accounts

service accounts are users managed by the Kubernetes API. They are bound to specific namespaces, and created automatically by the API server or manually through API calls

Normal User Authentication

A few steps are required in order to get a normal user to be able to authenticate and invoke an API. First, this user must have certificate issued by the Kubernetes cluster, and then present that Certificate to the API call as the Certificate Header or through the kubectl.

Authorization

https://kubernetes.io/docs/reference/access-authn-authz/authorization/

References

Certificate authority

https://www.ssl.com/faqs/what-is-a-certificate-authority/

EKS Authorization

https://caylent.com/eks-authentication-authorization https://github.com/kubernetes-sigs/aws-iam-authenticator#full-configuration-format https://docs.aws.amazon.com/eks/latest/userguide/add-user-role.html