3. Securing Access to Your K8 Application
● You are the administrator of an IT department who wants to deploy an application in a Kubernetes cluster.
● You want to avoid adopting a new authentication workflow.
● Users in your organization are accustomed to using their existing Active Directory credentials for accessing apps.
● Can you authenticate users against it when they access applications in Kubernetes?
Dex can help you!
● You’ve solved the authentication piece of the puzzle.
● Do you have different types of users?
○ Cluster administrators
○ App administrators
○ Read only users
● How do you grant varying levels of access to these users
Kubernetes has your RBAC!
4. What is Dex ?
● Dex is an identity service that uses OpenID Connect to drive authentication for other apps.
● Dex acts as a portal to other identity providers through “connectors.”
5. What is a connector?
Implements the logic for authenticating against an upstream IDP
● LDAP
● Openshift OAuth
● GitHub
● Google
6. Install Dex Using Helm
● helm repo add dex https://charts.dexidp.io
● helm install dex dex/dex -f dex-values.yaml
NAME: dex
LAST DEPLOYED: Wed Mar 17 21:06:49 2021
NAMESPACE: default
STATUS: deployed
REVISION: 1
TEST SUITE: None
NOTES:
1. Get the application URL by running these commands:
export POD_NAME=$(kubectl get pods --namespace default -l "app.kubernetes.io/name=dex,app.kubernetes.io/instance=dex" -o
jsonpath="{.items[0].metadata.name}")
export CONTAINER_PORT=$(kubectl get pod --namespace default $POD_NAME -o jsonpath="{.spec.containers[0].ports[0].containerPort}")
echo "Visit http://127.0.0.1:8080 to use your application"
kubectl --namespace default port-forward $POD_NAME 8080:$CONTAINER_PORT
11. Port Forwarding
kubectl --namespace dex port-forward $POD_NAME 8080:$CONTAINER_PORT
Forwarding from 127.0.0.1:8080 -> 5556
Forwarding from [::1]:8080 -> 5556
12. Install and Run the Example Application
● git clone https://github.com/dexidp/dex.git
● cd dex/examples/example-app
● go build
● ./example-app --issuer http://127.0.0.1:8080
2021/03/16 20:52:02 listening on http://127.0.0.1:5555
15. What is Kubernetes RBAC?
1. Kubernetes defines RBAC as “Role-based access control (RBAC) is a method of regulating access
to computer or network resources based on the roles of individual users within your organization.”
2. RBAC is a flexible and powerful method, where you define rules once and use them multiple times.
3. Allows access control over resources not just within a cluster but within the application as well.
4. Defines clearly “who” has access to “what”.
5. Allows for dynamically calculating access as applications change and grow.
16. Why do you need RBAC?
✓ Multi-tenancy is an important concern, especially as clusters and applications mature after the initial
hurdles of infrastructure and setup.
✓ How to restrict users access to just their applications and components within their applications is a
crucial administrative decision.
✓ Users can have their own setup and be unaware of other users in the same cluster/system.
✓ Allows separation and security between users and applications.
17. Roles and ClusterRoles
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
namespace: default
name: example-role
Rules: # multiple rules can be added
- apiGroups: [""]
resources: ["pods"]
verbs: ["get", "watch", "list"]
- apiGroups: [""]
resources: ["secrets"]
verbs: ["get", "watch", "list"]
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
# "namespace" omitted since ClusterRoles
are not namespaced
name: example-clusterole
rules:
- apiGroups: [""]
resources: ["secrets"]
verbs: ["create", "get"
, "watch", "list"]
20. RoleBindings
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: read-pods
namespace: default
subjects: # You can specify more than one "subject"
- kind: User
name: jane # "name" is case sensitive
apiGroup: rbac.authorization.k8s.io
roleRef: # "roleRef" specifies the binding to a Role / ClusterRole
kind: Role #this must be Role or ClusterRole
name: pod-reader # this must match the name of the Role or ClusterRole you wish to bind to
apiGroup: rbac.authorization.k8s.io
22. How, What, When?
Role v/s ClusterRole?
● Use Roles when rules are limited to a certain namespace
● Use ClusterRoles when rules are to be be defined across multiple namespaces and span
Resources/APIGroups not limited to a certain namespaces or if runtime namespace is not known in
advance
RoleBinding v/s ClusterRoleBinding?
● Use RoleBindings to limit subjects to a particular namespace
● Use ClusterRoleBindings to give cluster-wide access to subjects
Users v/s Groups?
● Use Users when specific user is known
● Use Groups to give all users belonging to the same group the same access level
23. How can I check what access a user has?
Kubectl auth can-i
✓ Kubectl tool to check user access
✓ Checks roles and bindings across the cluster to verify access
✓ Allows impersonation as user or group to verify access control across the list of subjects