Notes from episode 4 of TGIK: RBAC

Over the past few months I’ve been trying to learn everything there is to know about Kubernetes. Kubernetes is an amazing technology for deploying and scaling containers though it comes with a cost. It’s an incredibly complex piece of software and there are a ton of bells and whistles to become familiar with. One way that I’ve found for coming up to speed is Joe Beda’s weekly TGIK live broadcast. This occurs each Friday at 4PM EST and is CHOCK full of fantastic information. In episode four Joe talks about Role Based Access Control (RBAC). You can watch it here:

Here are some of my takeways from the episode:

• SSH command line to grab the kubeconfig from the quickstart master for local use (-W host:port can simplify this):
  $ scp -i $SSH_KEY -o proxyCommand="ssh -i \${SSH_KEY}" ubuntu@1.2.3.4 nc %h %p" ubuntu@2.3.4.5:~kubeconfig ./kubeconfig
• Heptio provides a super awesome RBAC cheat sheet on their website.
• Kubernetes configuration file layout:
  • cluster: contains the cluster to connect to.
    • certificate-authority-data: contains the RootCA certificate.
    • server: contains the server to connect to (https://path-to-api-server).
  • contexts: used to group access parameters under a convenient name
    • cluster: name of the cluster
    • namespace: namespace to use
    • user: username (this is the CN in the X509 certificate)
  • users: Contains the individual users and their security credentials
    • name: name of the user
    • user: attributes for the user (e.g., certificate and private key location)
• You can specify the kubeconfig you want to use with the KUBECONFIG environment variable.
• Each Kubernetes configuration file can contain multiple clusters and users.
• The kubectl “-v” option can be used to review the request/response headers sent between kubectl and the API server.
  $ kubectl -v 100 get pods
• View your Kubernetes configuration file:
  $ kubectl config view
• Numerous ways to authenticate to the Kubernetes API server:
  • X509 certificates
  • Static token file
  • Static password file
  • Service account tokens
  • OpenID connect
  • Webhook token authentication
  • Authenticating proxy
• Service accounts are useful for talking from on cluster (inside kubernetes) to the cluster.
• hashicorp vault can act as a certificate authority.
• Kubernetes has a built-in certificate authority. Useful for giving certifications to users.
• Jakub Scholz put together a cool document describing how to add users to Kubernetes.
• Kubernetes provides an API for signing certificates. To use it you can create a YAML file and base64 encode your CSR and assign it to the “request:” attribute. Then you can use kubectl to sign, approve and d/l your certificate (Jakub’s write up explains the commands further):
  $ kubectl create -f cert-request.yaml
  $ kubectl certificate approve matty
  $ kubectl get csr matty -o jsonpath='(.status.certificate} | base64 -d > matty.crt
• Currently no way to revoke certificates.
• Joe suggested using one cluster configuration for each cluster.
• Authentication defines who can do something. Authorizations defines what you can do.
• Authorization modes:
  • ABAC mode attribute based access control (mostly deprecated)
  • Webhook allows you to call a third party to control what something can can do
  • Node authorization limits what individual nodes can do
  • RBAC uses the authorization API to determine what something can do
• RBAC was back ported from openshift.
• Four key RBAC objects:
  • Roles
  • ClusterRoles
  • Rolbindings
  • ClusterRoleBindings
• Some objects in kubernetes (csr and nodes for example) don’t live in a specific namespace. These are cluster wide resources.
• Retrieve all roles and clusterroles:
  $ kubectl get roles --all-namespaces
  $ kubectl get clusterroles
• Individual services (daemonsets for example) in Kubernetes typically run under their own role.
• The cluster-admin role provides super use privileges (use cautiously).
• View the details of a specific role:
  $ kubectl get clusterroles system:basic-user -o yaml
• The verb in a role indicates the actions that can be performed.
• You can generate role binding templates with the dry-run option:
  $ kubectl create rolebinding matty --clusterrole=admin --user=users:matty --dry-run -o yaml
• Namespaces and RBAC are a great combo for isolating users to their own namespace and limiting what they can do in that namespace.
• Service accounts are used to connect to the cluster. These can be listed with kubectl:
  $ kubectl get sa
• If Francis Ford Coppola made a film about Kubernetes Joe would be the kubfather.

Things I need to learn more about:

• Learn more about the kubernetes certificate API.
• Learn more about how to properly use serviceaccounts.
• Play around with Hashicorps CA functionality.

This article was posted by Matty on 2018-02-07 20:19:49 -0500 -0500