The course is part of this learning path
With many enterprises making the shift to containers, along with Kubernetes being the leading platform for deploying container applications; learning Kubernetes Patterns is more essential than ever for application developers. Having this knowledge across all teams will lead to yielding the best results, for developers in particular.
This Kubernetes Patterns for Application Developers Course covers many of the Configuration, Multi-container Pods, and Services & Networking objectives of the Certified Kubernetes Application Developer (CKAD) exam curriculum.
Help prepare for the CKAD exam with this course, comprised of 6 expertly-instructed lectures.
- Understand and use multi-container patterns to get the most out of Kuberentes Pods
- Learn how to control network access to applications running in Kubernetes
- Understand how Kuberentes Service Accounts provide access control for Pods
- Use the Kubernetes command-line tool kubectl to effectively overcome challenges you may face when working with Kubernetes
This course is intended for application developers that are leveraging containers and using or considering using Kubernetes as a platform for deploying applications. However, there are significant parts of this course that appeal to a broader audience of Kubernetes users. Some individuals that may benefit from taking this course include:
- Application Developers
- DevOps Engineers
- Software Testers
- Kubernetes Certification Examinees
We would recommend that to successfully navigate this course it would be helpful to have:
- Knowledge of the core Kubernetes resources including Pods, and Deployments
- Experience using the kubectl command-line tool to work with Kubernetes clusters
- An understanding of YAML and JSON file formats
Related Training Content
This Course is part of the CKAD Exam Preparation Learning Path.
Your application running in a pod many to authenticate itself to gain access to cluster resources. That is the purpose of service accounts which we will cover in this lesson. We will start by explaining what service accounts are then we will see an example of how you configure service accounts, finally we'll touch on image pull secrets and how service accounts can help when you're working with the private container registry. Service accounts provide an identity to pods running in the cluster. Unlike users in Kubernetes which are managed by an external identity system and they are intended to be used by real people, service accounts are made for pods. Service accounts are also resources that are stored in and managed by the Kubernetes cluster.
Service accounts are namespace resources meaning they can only be used within one Kubernetes namespace and name of service accounts must be unique within the namespace but not across different namespaces. One of the main reasons for using service accounts is to utilize Role-Based Access Control or RBAC is securely mechanism built into Kubernetes. RBAC largely to define roles and associated permissions to access Kubernetes APIs and resources. For example, if your application needs to know the status of nodes in the cluster, our role allows you to grab those permissions. The same access control system is used to grab permissions to users in Kubernetes.
A Kubernetes administrator would usually define their roles since it requires knowledge of Kubernetes APIs and small mistakes could compromise the entire cluster. The actual mechanics of a pod authenticating itself involve using an authentication token that is automatically mounted into the pods file system. That token can be used as an authentication header for request center to Kubernetes APIs server. Every namespace has a default service account that is named default. Every pod that doesn't specify service account automatically uses a default service account. The default service account doesn't have any additional permissions than an authenticated user, making it secured by default. Those permissions are mainly limited to discovering what API the cluster provides but does not grab permission to use them, thereby denying access to any cluster state. Let's go see how service accounts can be configured.
You will work with service accounts first hand in the mastering Kubernetes pod configuration map if you are taking this course as part of the CKAD learning path. So this demo will just touch on a few key points. In a new cluster, the most interesting namespace from a service account perspective is keep system. The namespace reserves for system resources. Let's list the service accounts in Kube system. Because a lot of the pods in Kube system need access to different APIs and resources, there are many different service accounts. For example, cluster dns is provided by coredns and there is a service account for that. The default service account is also here as it would be in any other namespace. Just to get an idea of what a role looks like. Let's see the role that is bound to the coredns service account. In this case, it is actually a cluster role which means that it is not scoped to a specific namespace, instead, the role grabs permissions to all namespaces in the cluster. The cluster role is cloud system coredns and the described output gives the table showing the permissions granted.
The role gives permissions to get nodes and to list and watch endpoints, namespaces, services, and pods. That makes sense, as a dns service needs to know when pods and services are created so it can create dns records for accessing them but no write permission is needed. So how can you associate a pod with the service account? Let's take a look at the output of a coredns pod to see that. The service account name field is what needs to be set to associate a non-default service account. You can also see above that in the volumes for the container that the token is mounted at the var/run/secrets/kubernetes.io/serviceaccount path and that's all for this demo. Just before we wrap up this lesson, I want to add a note about service accounts and image pull secrets. Image pull secrets come into play when you're using a private container registry for your container images.
The way that you authenticate with the container registry so that you can pull an image into Kubernetes is by using image pull secrets. The secrets may be a docker registry server address user name and a password, for example, you can specify image pull secrets in pod specs directly but service accounts can also reference image pull secrets. Service accounts can provide both an authentication token and image pull secrets. It creates a nice separation of responsibilities when uses a service account for managing image pull secrets rather than hard coring your reference into pods specs. You can only modify the default service account to have image pull secrets so that any pod and a namespace can use images for your trusted registry without specifying a service account. That's all for this lesson where we covered the basic of service accounts. That they provide an identity to pods and in doing so, it enables Role Based Access Control for pods.
By default, every namespace has a default service account and it does not have any permissions beyond that of an authenticated user. Then we saw some examples of service accounts in the Kube system namespace and that the service account name field in a pod specs is how to configure the service accounts of a pod. Lastly, we learned that service accounts can also provide a convenient way to store image pull secrets. The next lesson will teach you how to get the most out of Kube control. There are useful tips if you plan to take the CKAD exam but also very useful in practice. Check it out when you are ready.
About the Author
Logan has been involved in software development and research since 2007 and has been in the cloud since 2012. He is an AWS Certified DevOps Engineer - Professional, AWS Certified Solutions Architect - Professional, MCSE: Cloud Platform and Infrastructure, Google Cloud Certified Associate Cloud Engineer, Certified Kubernetes Administrator (CKA), Certified Kubernetes Application Developer (CKAD), Linux Foundation Certified System Administrator (LFCS), and Certified OpenStack Administrator (COA). He earned his Ph.D. studying design automation and enjoys all things tech.