K8 RBAC:
*** IN AWS EKS Service accounts nothing but IAM roles PFB the Example:
resource "aws_eks_addon" "ebs_eks_addon" {
depends_on = [ aws_iam_role_policy_attachment.ebs_base_policy]
cluster_name = aws_eks_cluster.eks_cluster.name
addon_name = "aws-ebs-csi-driver"
service_account_role_arn = aws_iam_role.ebs_role.arn
}
service_account_role_arn = aws_iam_role.ebs_role.arn
Ref: https://github.com/RekhuGopal/PythonHacks/tree/main/Kuberenetes_RBACs
In K8 how the Authorizations is working.
In K8 how the Authentication is working.
K8 Resources are.
------------------------------------------------------------------------------------------------------------
User Account -- Admins or developers who can manage the k8 (for humans)
Service Accounts : it will assign on pod level (pods) its similar to aws iam roles
Roles : Permission at namespace level
ClusterRoles : Permission at cluster level
RoleBinding : Binding users/SA with role in namespace level
ClusterRoleBinding: Binding users/SA with role in cluster level
--------------------------------------------------------------------------------------------------------------
In Kubernetes, Role-Based Access Control (RBAC) is a security mechanism that defines and manages permissions for users, service accounts, and processes within a cluster. RBAC is crucial for ensuring that only authorized entities have access to specific resources and operations within the Kubernetes environment. Let's break down the key components of RBAC in Kubernetes:
User Accounts:
A user account represents an individual user. Users are typically authenticated externally to the Kubernetes cluster, and their identity is then associated with Kubernetes roles and permissions.
Users can be authenticated using various methods, such as certificates, bearer tokens, or external identity providers.
Service Accounts:
Service accounts are used to represent non-human entities, such as applications or processes, running within the cluster. They provide a way to control permissions and access for these internal entities.
Service accounts are associated with a set of roles or cluster roles, defining the permissions granted to the service account.
Roles and Cluster Roles:
A role is a set of permissions that define actions a user, or a service account, can perform on a set of resources within a specific namespace.
A cluster role is similar to a role but is not namespace-specific. It provides permissions across the entire cluster.
Both roles and cluster roles are defined using YAML manifests and include rules specifying API groups, resources, verbs, and namespaces.
By default to make or fix the namespace.
kubectl config set-context --namespace=namespace-name --curent
Example Role & Cluster Role:
---
kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
namespace: default
name: pod-reader
rules:
- apiGroups: [""]
resources: ["pods"] # either its pods are deployment or services k8 resources
verbs: ["get", "list"] # To give the access like get list create and delete
# api group indicates the kubectl api-resources (part of k8 V1 it will include)
---
kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
name: pod-reader
rules:
- apiGroups: [""]
resources: ["pods"]
verbs: ["get", "list"]
Role Binding and ClusterRole Binding:
A role binding associates a role with a user or a group of users within a specific namespace. It binds a role to a set of subjects, such as users or service accounts.
A cluster role binding is similar to a role binding but is not namespace-specific. It associates a cluster role with subjects across the entire cluster.
Example Role Binding & ClusterRole Binding:
---
kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
name: read-pods
namespace: default
subjects:
- kind: User
name: john.doe
apiGroup: rbac.authorization.k8s.io
roleRef:
kind: Role
name: pod-reader
apiGroup: rbac.authorization.k8s.io
---
kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
name: read-pods-cluster
subjects:
- kind: User
name: john.doe
apiGroup: rbac.authorization.k8s.io
roleRef:
kind: ClusterRole
name: pod-reader
apiGroup: rbac.authorization.k8s.io
----------------------------RBAC in AWS EKS---------------------------------------------
aws iam create-user --user-name rbac-user
aws iam create-access-key --user-name rbac-user | tee /tmp/create_output.json
get the aws config file.
kubectl get configmap -n kube-system aws-auth -o yaml
under data add the below created user
data:
mapUsers: |
- userarn: arn:aws:iam::${ACCOUNT_ID}:user/rbac-user
username: rbac-user
Example total file will be like below
kubectl apply -f aws-auth.yaml
Lets validate:
aws sts get-caller-identity
kubectl get pods -n rbac-test
Log in as admin for the firsttime by using eks created role or user
---------------------Giving access to diff role and users in aws iam-----------------------
Lets create 2 new iam role's
aws iam create-role --role-name eks-role-1 --assume-role-policy-document file://trust-policy.json
aws iam create-role --role-name eks-role-2 --assume-role-policy-document file://trust-policy.json
in kube-system namespace add the file
apiVersion: v1
kind: ConfigMap
metadata:
name: aws-auth-role-1
namespace: kube-system
data:
mapRoles: |
- rolearn: <eks-role-1-arn>
username: role-1
groups:
- system:masters
- rolearn: <eks-role-2-arn>
username: role-2
groups:
- system:masters
---
# IAM Roles
---
apiVersion: v1
kind: ServiceAccount
metadata:
name: eks-role-1
namespace: kube-system
---
apiVersion: v1
kind: ServiceAccount
metadata:
name: eks-role-2
namespace: kube-system
# ConfigMaps for role mapping
---
apiVersion: v1
kind: ConfigMap
metadata:
name: aws-auth-role-1
namespace: kube-system
data:
mapRoles: |
- rolearn: <eks-role-1-arn>
username: eks-role-1
groups:
- system:masters
---
apiVersion: v1
kind: ConfigMap
metadata:
name: aws-auth-role-2
namespace: kube-system
data:
mapRoles: |
- rolearn: <eks-role-2-arn>
username: eks-role-2
groups:
- system:masters
# RBAC Setup
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: pod-viewer
rules:
- apiGroups: [""]
resources: ["pods", "deployments"]
verbs: ["get", "list"]
resourceNames: [""] # empty means all resources
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
name: eks-role-1-binding
subjects:
- kind: ServiceAccount
name: eks-role-1
namespace: kube-system
roleRef:
kind: ClusterRole
name: pod-viewer
apiGroup: rbac.authorization.k8s.io
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
name: eks-role-2-binding
subjects:
- kind: ServiceAccount
name: eks-role-2
namespace: kube-system
roleRef:
kind: ClusterRole
name: pod-viewer
apiGroup: rbac.authorization.k8s.io
--------------------------------------------------------------------------------------------------
Using role & role binding with config map minimal access:
# IAM Roles
---
apiVersion: v1
kind: ServiceAccount
metadata:
name: eks-role-1
namespace: kube-system
---
apiVersion: v1
kind: ServiceAccount
metadata:
name: eks-role-2
namespace: kube-system
# ConfigMaps for role mapping
---
apiVersion: v1
kind: ConfigMap
metadata:
name: aws-auth-role-1
namespace: kube-system
data:
mapRoles: |
- rolearn: <eks-role-1-arn>
username: eks-role-1
groups:
- view
---
apiVersion: v1
kind: ConfigMap
metadata:
name: aws-auth-role-2
namespace: kube-system
data:
mapRoles: |
- rolearn: <eks-role-2-arn>
username: eks-role-2
groups:
- view
# RBAC Setup with Role and RoleBinding
---
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
name: pod-viewer
namespace: kube-system
rules:
- apiGroups: [""]
resources: ["pods", "deployments"]
verbs: ["get", "list"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: eks-role-1-binding
namespace: kube-system
subjects:
- kind: ServiceAccount
name: eks-role-1
namespace: kube-system
roleRef:
kind: Role
name: pod-viewer
apiGroup: rbac.authorization.k8s.io
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: eks-role-2-binding
namespace: kube-system
subjects:
- kind: ServiceAccount
name: eks-role-2
namespace: kube-system
roleRef:
kind: Role
name: pod-viewer
apiGroup: rbac.authorization.k8s.io
** We can use the cluster role in rolebinding. where as in clusterrolebinding we won't use role because of namespace
0 Comments