Container Security (part 3 of 3)

By Ashwin Venugopal -

 



To read part 1 of 3 please click here
To read part 2 of 3 please click here

Azure Kubernetes Service (AKS)

Kubernetes is a rapidly evolving platform that manages container-based applications and their associated networking as well as storage components while supporting both the stateless and stateful applications as teams progress through the adoption of microservices-based applications. As an open platform, it also allows you to build your applications with your preferred programming language, OS, libraries, or messaging bus. 
AKS provides a managed kubernetes service that reduces the complexity for deployment and core management tasks, including coordinating upgrades. AKS is built on top of the open-source Azure Kubernetes Service Engine (aks-engine) and you only pay for the AKS nodes that run your applications. 

Features of AKS

  • Fully managed
  • Public IP and FQDN (private IP option)
  • Accessed with RBAC or Azure AD
  • Deployment of containers
  • Dynamic scale containers
  • Automation of rolling updates and rollbacks of containers
  • Management of storage, network traffic, and sensitive information  

AKS Architecture

Kubernetes cluster architecture

Cluster Master
When you create an AKS cluster, a cluster master is automatically created and configured and there is no cost for the cluster master, only for the nodes that are part of the AKS cluster. The cluster master includes the following core kubernetes componenets:
  • kube-apiserver- The API server is how the underlying Kubernetes APIs are exposed. This component provides the interaction for management tools, such as kubect1 or the kubernetes dashboard.
  • etcd- To maintain the state of your kubernetes cluster and configuration, the highly available etcd is the key value stored within kubernetes.
  • kube-scheduler- When you create or scale applications, the Scheduler determines what nodes can run the workload and start them.
  • kube-controller-manager- The Controller Manager oversees a number of smaller Controllers that perform actions such as replicating pods and handling node operations.  
The managed cluster master means that you do not need to configure components like a highly available store, but it also means that you cannot access the cluster master directly, but if you need to configure the cluster master in a particular way or need direct access to them, then you can deploy your own kubernetes cluster using aks-engine.

Nodes and node pools

An AKS cluster has one or more nodes, which is an Azure VM that runs the Kubernetes node component and container runtime:
  • The kubelet is the Kubernetes agent that processes the orchestration requests from the control plane and scheduling of running the requested containers.
  • Virtual networking is handled by the kube-proxy on each node. the proxy routes network traffic and manages IP addressing for services and pods.
  • The container runtime is the component that allows containerized applications to run and interact with additional resources such as the virtual network and storage. In AKS, Moby is used as the container runtime.
In AKS, the VM image for the nodes in your cluster is currently based on Ubuntu Linux or Windows Server 2019. Agent nodes are billed as standard virtual machines, so any discounts you have on the VM size you are using (including Azure reservations), are automatically applied.

Node Security

AKS nodes are Azure VMs that you can manage and maintain. The Azure platform automatically applies OS security patches to Linux nodes on a nightly basis and you can manually reboot the Linux nodes, or a common approach is to use Kured, an open-source reboot daemon for Kubernetes which are managed across the cluster using the same cordon and drain process as a cluster upgrade.

For Windows Server nodes, Windows Update does not automatically run and apply the latest updates. You should perform an upgrade on the Windows Server node pool(s) in your AKS cluster which creates nodes that run the latest Windows Server image and patches, then remove the older nodes. 

Nodes are deployed into a private virtual network subnet, with no public IP addresses assigned and to provide storage, the nodes use Azure Managed Disks as well as improve the redundancy, these disks are also securely replicated within the Azure datacenter. 

To protect your customer data as you run application workloads in AKS, the security of your cluster is a key consideration. 

AKS Networking

To allow access to your applications, or for application components to communicate with each other, Kubernetes provides an abstraction layer to virtual networking. In Kubernetes, Services logically group pods to allow for direct access via an IP address or DNS name and on a specific port. Security and filtering of the network traffic for pods is possible with Kubernetes network policies.  
The Azure platform also helps to simplify virtual networking for AKS clusters. As you open network ports to pods, the corresponding Azure network security group rules are configured. For HTTP application routing, Azure can also configure external DNS as new ingress routes are configured. 

Services

Kubernetes uses Services to logically group a set of pods together and provide network connectivity. The following service types are available:
  • Cluster IP- Creates an internal IP address for use within the AKS cluster. Good for internal-only applications that supports other workloads within the cluster.
  • NodePort- Creates a port mapping on the underlying node that allows the application to be accessed directly with the node IP address and port.
  • LoadBalancer- Creates an Azure load balancer resource, configures an external IP address, and connects the requested pods to the load balancer backend pool. 
  • ExternalName- Creates a specific DNS entry for easier application access. 

The Network Policy feature in Kubernetes lets you define rules for ingress and egress traffic between pods in a cluster. 

Volumes

Traditional volumes to store and retrieve data are created as Kubernetes resources backed by Azure storage. These data volumes can use Azure Disks or Azure Files:
  • Azure Disks can be used to create Kubernetes DataDisk resource. They are mounted as ReadWriteOnce, hence are only available to a single pod. For storage volumes that can be accessed by multiple pods simultaneously, use Azure Files.
  • Azure Files can be used to mount an SMB 3.0 share backed by an Azure Storage account to pods. Files let you share data across multiple nodes as well as pods and can use Azure Standard storage backed by regular HDDs, or Azure Premium storage, backed by high performance SSDs. 

Storage Classes

To define the different tiers of storage, such as Premium and Standard, you can create a StorageClass which also defines the reclaimPolicy. In AKS two initial StorageClasses are created:
  • default- Uses Azure Standard storage to create a Managed Disk. The reclaim Policy indicates that the underlying Azure Disk is deleted when the persistent volume that used it is deleted.
  • managed-premium- Uses Azure Premium storage to create Managed Disk. The reclaim Policy again indicates that the underlying Azure Disk is deleted when the persistent volume that used it is deleted. 
If no StorageClass is specified for a persistent volume, the default StorageClass is used.

Kubernetes Service Accounts

One of the primary user types in Kubernetes is a service account while the credentials for service accounts are stored as Kubernetes secrets, which allows them to be used by authorized pods to communicate with the API server. Most API requests provide an authentication token for a service account or a normal use account.
Normal user accounts allows more traditional access for human administrators or developers, not just services and processes while the external identity solutions can be integrated into Kubernetes, and this integrated identity solution is Azure Active Directory.

Azure Active Directory Integration

The security of AKS clusters can be enhanced with the integration of Azure Active Directory through which you can integrate on-premises identities into AKS clusters to provide a single source for account management and security. The Azure AD-integrated AKS clusters can grant users or groups access to Kubernetes resources within a namespace or across the cluster while providing a single source for user account management and password credential. The user can only access the resources as defined by the cluster administrator.

AKS and RBAC

One additional mechanism for controlling access to resources is  Azure Role-Based Access Controls (RBAC). With Azure RBAC, you can create a role definition that outlines the permissions to be applied. A user or group is then assigned this role definition for a particular scope, which could be an individual resource, a resource group, or across the subscription.

Roles and ClusterRoles

Roles are used to grant permissions within a namespace. But if you need to grant permissions across the entire cluster, or to cluster resources outside a given namespace, you can instead use ClusterRoles. A ClusterRole works in the same way to grant permissions to resources, but can be applied to resources across the entire cluster, not a specific namespace.

RoleBindings and ClusterRoleBindings

Role bindings are used to assign roles for a given namespace. This lets you logically segregate a single AKS cluster, with users only able to access the application resources in their assigned namespace. If you need to bind roles across the entire cluster, or to cluster resources outside a given namespace, you can instead use ClusterRoleBindings. This approach lets you grant administrators or support engineers access to all resources in the AKS cluster. 

Kubernetes Secrets

A Kubernetes Secret is used to inject sensitive data into pods, such as access credentials or keys. Secrets are only provided to the nodes that have a scheduled pod that requires it, and it is stored in tmpfs, not written to disk. They are stored within a given namespace and can only be accessed by the pods within the same namespace.

The use of Secrets reduces the sensitive information that is defined in the pod or service YAML manifest. Instead, you can request the Secret stored in Kubernetes API server as a part of your YAML manifest that only provide the specific pod access to the Secret. However, the raw secret manifest files contains the secret data in base64 format, therefore, this file should be treated as sensitive information, and never committed to source control.  

The secrets are written in the clear text on the node's volume which means the customers have to do two things:
  • Use file ACLs to secure the secrets file location.
  • Use volume-level encryption using BitLocker.    
   

 
To read part 1 of 3 please click here
To read part 2 of 3 please click here













Comments

Post a Comment

Popular posts from this blog

Query, Visualize, & Monitor Data in Azure Sentinel

By Ashwin Venugopal -
Image
  Azure Sentinel Workbooks Several ready for use templates are provided by the Azure Sentinel that can be used to create your own workbook and then modify them as needed for Contoso. Most of the data connectors it uses to ingest data come with their own workbooks, but better insight can be obtained by simply looking into the data that is being ingested by using tables and visualizations, including bar and pie charts. You can also make your own workbook easily by using this data from the beginning instead of using the predefined templates. Workbook Page You can easily access the workbook page from the Azure Sentinel from the navigation pane which consists of the: Workbook header- You can add a new workbook and review the saved workbooks as well as templates that are available on the workbook page. Templates section- You can access existing workbook templates on the Templates tab. You can save some of the workbooks for quick access and they will appear on the My Workbooks tab.  From the
Read more

Planning for Implementing SAP Solutions on Azure (Part 2 of 5)

By Ashwin Venugopal -
Image
  To read part 1 please click  here To read part 3 please click  here To read part 4 please click  here To read part 5 please click  here Load Balancing The load balancer uses probe ports to determine as well as route the traffic to an active DBMS node, but of there's any failover then the most common SAP application architecture can automatically reconnect against the private virtual IP address without the need for the SAP application to reconfigure it, while the load balancer redirect the traffic against the private virtual IP address without any need for the SAP application to reconfigure. The loaf balancer also offers an option of DirectServerReturn which if configured, can help in directing the traffic from the DBMS VM to the SAP application layer directly to the application layer without routing through the load balancer. But, if it isn't configured, then the return traffic to the SAP application layer is routed through the load balancer. You can also use Azure Load Balan
Read more

Work with String Data Using KQL Statements

By Ashwin Venugopal -
Image
  Extract Data from Unstructured String Fields Unstructured string fields often contains the Security log data and requires parsing to extract data. There are multiple ways of pulling information from string fields in KQL and the two primary operators used are extract and parse.  Extract It gets a match for a regular expression from a text string. You can convert the extracted substring to the indicated type.  Arguments regex- A regular expression. captureGroup- A positive int constant indicating the capture group to extract. 0 stands for the entire match, 1 for the value matched by the first '('parenthesis')' in the regular expression, 2 or more for subsequent parenthesis.  text- A string to search. typeLiteral- An optional type literal. If provided, the extracted substring is converted to this type.  Returns If regex finds a match in text- the substring matched against the indicated capture group captureGroup, optionally converted to typeLiteral. If there's no mat
Read more