Kasten securing access to your kubernetes applications

Securing Access to Your Kubernetes Applications
Using Dex for Authentication
&
Role Based Access Control (RBAC) for Authorization

Deepika Dixit
Software Engineer
Introductions
Onkar Bhat
Engineering Manager

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!

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.”

What is a connector?
Implements the logic for authenticating against an upstream IDP
● LDAP
● Openshift OAuth
● GitHub
● Google

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

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

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

Demo
Claims:
{
"iss": "http://127.0.0.1:8080",
"sub": "CgVvbmthchIEbGRhcA",
"aud": "example-app",
"exp": 1616037593,
"iat": 1615951193,
"at_hash": "S9b817ZpFhdA6Ezw-nEEdA",
"email": "onkar",
"email_verified": true,
"groups": [
"K10admins"
],
"name": "onkar",
"preferred_username": "onkar"
}

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.

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.

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"]
kind: ClusterRole
metadata:
# "namespace" omitted since ClusterRoles
are not namespaced
name: example-clusterole
rules:
- apiGroups: [""]
resources: ["secrets"]
verbs: ["create", "get"
, "watch", "list"]

Rules and Resources
kind: Role
metadata:
namespace: default
name: example-role
rules:
- apiGroups: ["mygroup.example.com"
]
resources: ["pods"]
resourceNames: ["mypod"]
kind: Role
metadata:
namespace: default
name: example-role-all
rules:
- apiGroups: ["*"]
resources: ["*"]
verbs: ["*"]

Subjects
Users
subjects:
- kind: User
name:
"alice@example.com"
Groups
subjects:
- kind: Group
name:
"frontend-admins"
Service Account
subjects:
- kind: ServiceAccount
name: default
namespace:
kube-system

RoleBindings
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

ClusterRoleBindings
kind: ClusterRoleBinding
metadata:
name: read-secrets-global
subjects:
- kind: Group
name: manager # Name is case sensitive
- kind: ServiceAccount
name: test-sa
namespace: default
roleRef:
kind: ClusterRole
name: secret-reader

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

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

References
RBAC
https://kubernetes.io/docs/reference/access-authn-authz/rbac/
Dex
https://dexidp.io/
https://github.com/dexidp/helm-charts
#dexidp at kubernetes.slack.com
https://aws.amazon.com/blogs/security/how-to-configure-ldaps-endpoint-for-simple-ad/

Kasten securing access to your kubernetes applications

Related slideshows

Recommended for you

Recommended for you

Recommended for you

Recommended for you

Recommended for you

Recommended for you

More Related Content

What's hot

What's hot (20)

Similar to Kasten securing access to your kubernetes applications

Similar to Kasten securing access to your kubernetes applications (20)

More from LibbySchulze

More from LibbySchulze (20)

Recently uploaded

Recently uploaded (20)

Kasten securing access to your kubernetes applications