In this article, we will be discussing some of the security-related practices we can follow across the cloud infrastructure or on Kubernetes cluster, that can help us create a secure environment for our production systems.
Micro-segmentation
Micro-segmentation enables consolidation of workloads with differing security needs. An example could be running workloads of a production environment with a test environment, or within an application environment, running public and private components.
This is implemented by enforcing security policies around each individual workload in the environment. By placing security controls next to the workloads themselves, security policies become asset-specific and as a result, workloads at different security levels can now share common infrastructure, enabling much greater consolidation and agility.
Micro-segmentation is an emerging security best practice that offers a number of advantages over more established approaches. The added granularity that micro-segmentation offers is essential at a time when many organizations are adopting cloud services and new deployment options like containers that make traditional perimeter security less relevant.
Single sign-on (SSO)
Single Sign-On (SSO) allows users to log in using a single set of credentials, e.g. username and password, so they can easily access a set of applications. SSO. SSO saves time and energy for users because they do not have to repeatedly log into multiple applications. This provides a smooth user experience, and makes it less likely to have access problems because of lost or forgotten credentials, locked-out accounts, etc. Instead of having individual authentication on various tools, a more effective strategy is to use single sign-on for all tools, i.e. a centralized authentication mechanism that can allow or reject access to a set of tools based on a single set of credentials per user. Additionally, some tools may not have authentication built into them at all, and may be reliant on an external authentication server in any case. An external authentication server with single sign-on capability can therefore prove to be the way to go in such a situation.
You can read a discussion on this here.
IP whitelisting
IP whitelisting allows you to create lists of trusted IP addresses or IP ranges from which your users can access your domains. On AWS, this can be implemented with security groups which act as virtual firewalls for your instance to control inbound and outbound traffic. Security groups act at the instance level, not the subnet level. Therefore, each instance in a subnet in your VPC could be assigned to a different set of security groups. For each security group, you add rules that control the inbound traffic to instances, and a separate set of rules that control the outbound traffic.
Secrets Management in Kubernetes
Sensitive information such as a database password or an API key should not be stored in clear text. And these should not be written into the container image. The 12-factor app philosophy says that configuration including secrets should come from the environment. Kubernetes provides the resource type Secrets for this. Kubernetes Secrets provide a mechanism to use such information in a safe and reliable way
Secrets are namespaced objects, i.e. they exist in the context of a namespace
You can access them via a volume or an environment variable from a container running in a pod
The API server stores secrets as plaintext in etcd
Applying the Principle of Least Privilege, We want to ensure that containerized code can read only the secrets that it needs. And also a good idea is to have a different set of secrets for different environments (like production, development, and testing). The development and test credentials can be shared with a wider set of team members without necessarily giving them full access to the production credentials.
There are three ways to get secrets (or any other kind of information) into a container so that they are accessible to the application:
Building them into the image itself
Passing them into the container as environment variables
Mounting a volume into a container so that code can read the information out of a file on that volume
Kubernetes secrets support the last two of these approaches, although the third option of mounting a volume is generally considered the safest.
Following GitOps principles, we would like to maintain our configuration and secrets in version control with respect to the relevant environment. However committing secrets into version control in plane text is not a good idea. But we still want them to be versioned and maintained with the environment configuration, and be accessible to multiple developers/ops or target systems.
For this, we can commit encrypted secrets into our version control, and decrypt them when we need to use. This becomes easy when using Helm, since Helm has a plugin for this, Helm secrets.
Helm secrets:
Allows encryption of values, so that they can be checked into version control
Track which secrets were changed at what time in the version control system
Values files are encrypted with a secret key.
The plugin supports the yaml structure encryption per value, i.e. it only encrypts the values
The following diagram illustrates this flow.
Role Based Access Control
Role-based access control (RBAC) is a method of regulating access to computer or network resources based on the roles of individual users. All resources are modeled API objects in Kubernetes, belonging to API Groups. These resources allow operations such as Create, Read, Update, and Delete (CRUD). RBAC is writing rules to allow or deny operations on resources by users, roles or groups.
Rules are operations which can act upon an API group.
Roles are a group of rules which affect, or scope, a single namespace
ClusterRoles have a scope of the entire cluster.
Each operation can act upon one of three subjects
User Accounts
Service Accounts
Groups
Here is a summary of the RBAC process:
Determine or create namespace
Create certificate credentials for user
Set the credentials for the user to the namespace using a context
Create a role for the expected task set
Bind the user to the role
Verify the user has limited access.