DEV Community: Abhinav Dadhich

Simplifying Access Control in EKS: A Guide to AWS EKS Cluster Access Management

Abhinav Dadhich — Tue, 17 Sep 2024 08:19:05 +0000

Previously Providing access to an EKS cluster or specific application-based access can be a complex process. Kubernetes leverages Role-Based Access Control (RBAC) to manage these permissions, allowing cluster administrators to assign access based on user roles within the organization. EKS integrates RBAC with AWS IAM roles, which makes it highly effective for handling authorization.

Consider this scenario: different teams may require various levels of access to the cluster—like the monitoring team needing access to the monitoring namespace, or the development team requiring read-only access to the dev namespace. In such cases, the administrator defines these permissions using RBAC, mapping AWS IAM identities to Kubernetes roles. This mapping is achieved through a ConfigMap called aws-auth, located in the kube-system namespace, where AWS roles are linked to Kubernetes users and groups.

This combination of RBAC and AWS IAM provides a flexible, scalable, but a complex process to manage fine-grained access control in EKS clusters, simplifying how permissions are handled for multiple teams with distinct access needs.

Historically, cluster creation was handled via Amazon EKS APIs, but administrators had to switch to the Kubernetes API to define mappings between AWS IAM users and their Kubernetes permissions. This approach introduced complexity, making the process of granting access to EKS clusters cumbersome and leaving “shadow administrator” (root-level) permissions with the principal who created the cluster.

In December 2023, AWS launched a new feature called EKS Cluster Access Management. This simplifies the process of granting and managing access within EKS clusters. Instead of relying on the aws-auth ConfigMap, access can now be managed through the AWS API directly. This new feature is supported in EKS versions starting from v1.23.

What is Shadow administrator: In Amazon EKS, the user who initially creates the cluster is automatically granted administrative privileges, although this access isn't explicitly visible in the usual permission settings. This user, often referred to as a "shadow administrator," has full control over the cluster by default. EKS Cluster Access Management introduces a solution for identifying and managing these shadow administrators, making their presence visible within the IAM access entries on the cluster’s access management page. This feature allows administrators to audit, modify, or revoke these hidden privileges, enhancing transparency and control over cluster access.

two key concepts—'access entries' and 'access policies'—form the foundation for managing permissions

Access Entries: When you grant access to an AWS principal (such as a user or service), you create an access entry specific to that principal. This entry serves as a gateway for assigning permissions through Kubernetes groups or by linking it to access policies. The access entry centralizes control over what an AWS principal can do within the EKS cluster.

Access Policies: These are EKS-specific policies designed to control Kubernetes permissions for access entries. Unlike AWS IAM policies, they are defined within Amazon EKS and offer flexibility in how permissions are granted. You can apply an access policy either at the cluster level (similar to a Kubernetes ClusterRole) or the namespace level (analogous to a Role). Each policy defines a set of Kubernetes permissions curated by AWS, simplifying the assignment of access rights.

Kubernetes access management in Amazon EKS is governed by a cluster-wide setting known as the authentication mode. In EKS, there are three distinct authentication modes that determine how access permissions are managed:

API_AND_CONFIG_MAP: Both the aws-auth ConfigMap and Access Entries are considered in this mode. However, if an AWS principal is defined in both the ConfigMap and an Access Entry, the Access Entry takes precedence, and the permissions granted in the ConfigMap are ignored. This mode provides a hybrid approach, combining traditional ConfigMap-based access with Access Entries for more flexibility. By default, API_AND_CONFIG_MAP is selected for clusters using the latest versions of EKS, offering an optimal balance of control and convenience.

CONFIG_MAP: In this mode, the control plane solely relies on the aws-auth ConfigMap to manage access. No Access Entries can be created within the cluster, and all permissions must be explicitly defined in the ConfigMap.

API: This mode bypasses the aws-auth ConfigMap entirely, relying exclusively on Access Entries to manage permissions. This is ideal for organizations looking to centralize access control directly within the EKS environment.

CLI Commands for Managing AWS EKS Access

To ensure compatibility with AWS EKS commands, make sure you're using the latest version of the AWS CLI. Some commands may not work with older versions.

Modify the Authentication Mode:
aws eks update-cluster-config --name <CLUSTER_NAME> --access-config authenticationMode=API

List Access Policies:
aws eks list-access-policies

List Access Entries in Your Cluster:
aws eks list-access-entries --cluster-name <cluster-name>

Create an Access Entry for an IAM User:
aws eks create-access-entry --cluster-name demo-cluster \ --principal-arn arn:aws:iam::${ACCOUNT_ID}:user/cluster-admin

Associate AmazonEKSClusterAdminPolicy to the Access Entry:
aws eks associate-access-policy --cluster-name demo-cluster \ --principal-arn arn:aws:iam::${ACCOUNT_ID}:user/cluster-admin \ --policy-arn arn:aws:eks::aws:cluster-access-policy/AmazonEKSClusterAdminPolicy \ --access-scope type=cluster

When creating access entries in Amazon EKS, you have several options tailored to different types of IAM principals:

STANDARD: This is the default type, used for IAM users and roles. You can also utilize Kubernetes RBAC authorization with STANDARD access entries, allowing you to assign one or more Kubernetes group names to the entry.

EC2 Linux, EC2 Windows, and FARGATE_LINUX: These types are specific to different compute environments.

However, there are important considerations to keep in mind:

Service Linked Roles: Access entries cannot be created for service-linked roles.

Unique IAM Principal: Each access entry must include the Amazon Resource Name (ARN) of a single, unique IAM principal. An IAM principal cannot be associated with more than one access entry.

Immutability: Once an access entry is created, you cannot change its IAM principal or type.

Deletion of IAM Principals: If an IAM principal is deleted, the associated access entry will not be automatically removed. You must manually delete the access entry.

Understanding these constraints ensures effective management of access entries and helps maintain a secure and organized cluster environment.

Switching authentication modes

on an existing EKS cluster is a one-way operation, with specific pathways for transition:

CONFIG_MAP to API_AND_CONFIG_MAP: You can move from the CONFIG_MAP mode to API_AND_CONFIG_MAP, which allows for a combined approach using both the aws-auth ConfigMap and Access Entries.

API_AND_CONFIG_MAP to API: You can also transition from API_AND_CONFIG_MAP to API, which focuses solely on Access Entries and ignores the aws-auth ConfigMap.

However, once you make these transitions, reverting to a previous mode is not permitted:

API to CONFIG_MAP or API_AND_CONFIG_MAP: You cannot switch back to CONFIG_MAP or API_AND_CONFIG_MAP after moving to API.

API_AND_CONFIG_MAP to CONFIG_MAP: Similarly, once you have transitioned from CONFIG_MAP to API_AND_CONFIG_MAP, reverting directly to CONFIG_MAP is not allowed.

This one-way nature of authentication mode changes ensures that once a new access management approach is adopted, it cannot be reversed, allowing for a consistent and predictable security posture.

Note

Access entries and access policies take precedence over configurations in the aws-auth ConfigMap. For example, if a user has read-only access assigned in the aws-auth ConfigMap but has been granted ClusterAdmin access via the AWS API, the user will be granted ClusterAdmin privileges.

How to Configure & Setup Azure DevOps Self Hosted Linux Runner as a Systemd service

Abhinav Dadhich — Thu, 25 Jul 2024 15:19:35 +0000

To build your code or deploy your software using Azure Pipelines, you need at least one agent. As you add more code and people, you'll eventually need more.

When your pipeline runs, the system begins one or more jobs. An agent is computing infrastructure with installed agent software that runs one job at a time.

Azure Pipelines provides several different types of agents.

Microsoft-hosted agents (Agents hosted and managed by Microsoft).
Self-hosted agents (Agents that you configure and manage, hosted on your VMs).
Azure Virtual Machine Scale Set agents (A form of self-hosted agents, using Azure Virtual Machine Scale Sets, that can be auto-scaled to meet demands).

In this document, we will cover how to set up a self-hosted runner on an Ubuntu machine, configuring it to run as a systemd service.

Prerequisites:

Microsoft Account: Ensure you have a Microsoft account set up.
Azure Account and Subscription: Set up your Azure account and ensure you have an active subscription.
Azure Virtual Machine: Create a VM running Ubuntu 22.04 in the Azure Cloud.
Personal Access Token: Generate a Personal Access Token (PAT) in Azure DevOps.

Steps to Configure Self Hosted in Ubuntu Machine

In your web browser, navigate to Agent pools:

Sign in to your organization (https://dev.azure.com/{yourorganization}).
Choose Azure DevOps, Organization settings.

Choose Agent pools.

ADD a new Agent pool (Click on ADD Pool and then select Self Hosted)

Setup a New Agent

Click on Linux (As we are using Linux Machine), and then copy the URL to download the agent in your Ubuntu Machine.

Login to your Azure VM and then execute these following commands to download and setup your agent

mkdir myagent && cd myagent
wget https://vstsagentpackage.azureedge.net/agent/3.242.1/vsts-agent-linux-x64-3.242.1.tar.gz
tar zxvf vsts-agent-linux-x64-3.242.1.tar.gz
./config.sh

Note : Configure your Agent by Answering these following questions
"Enter server URL" > https://dev.azure.com/{yourorganization}/
"Enter authentication type (press enter for PAT)" >
"Enter personal access token" >
"Enter agent pool (press enter for default)" >
"Enter agent name (press enter for AZDevops-test-runner)" >

Configure the Agent to run as a Service

sudo ./svc.sh install &
./runsvc.sh &

Now Follow these steps to run this service as a systemd service

Create a file called /etc/systemd/system/MyTestAgent.service

[Unit]
Description=Runner_AD
After=network.target
StartLimitIntervalSec=0
[Service]
#User=root
User=azureuser
#Restart=on-failure
ExecStart=/home/azureuser/myagent/runsvc.sh
StandardOutput=syslog
StandardError=syslog
#Change this to find app logs in /var/log/syslog
SyslogIdentifier=adrunner
[Install]
WantedBy=multi-user.target

Your runsvc.sh should look like this (Make the changes accordingly)

#!/bin/bash

# convert SIGTERM signal to SIGINT
# for more info on how to propagate SIGTERM to a child process see: http://veithen.github.io/2014/11/16/sigterm-propagation.html
trap 'kill -INT $PID' TERM INT

if [ -f ".path" ]; then
    # configure
    export PATH=`cat .path`
    echo ".path=${PATH}"
fi

# insert anything to setup env when running as a service

# fallback on Node16 if Node20 is not supported by the host
./externals/node20_1/bin/node --version
if [ $? == 0 ]; then
    NODE_VER="node20_1"
else
    NODE_VER="node16"
fi

# run the host process which keep the listener alive
./externals/"$NODE_VER"/bin/node ./bin/AgentService.js &
PID=$!
wait $PID
trap - TERM INT
wait $PID

sudo systemctl daemon-reload
sudo systemctl enable MyTestAgent.service
sudo systemctl start MyTestAgent.service
sudo systemctl status MyTestAgent.service

Voila! We have successfully Configured & Setup Azure DevOps Self Hosted Linux Runner as a Systemd service.