LDAP Webhook authentication and authorisation plugin. k8s LDAP authn-authz middleware that can talk to your ldap server, and have configurable authentication and authorisation rules based on ldap groups or user specific overrides.
To run k8s-ldap:
1. openssl req -x509 -newkey rsa:2048 -nodes -subj "/CN=localhost" -keyout key.pem -out cert.pem
2. go build .
3. ./k8s-ldap <your ldap server address> key.pem cert.pem
Your config file should be available in the same directory.
Configuration options:
-
"BindDomain" : "example.com" (Optional) Bind Domain is only used if your username does not contain the domain. For example, if your username is jack.johnson, but you need jack.johnson@example.com to be able to bind to ldap. Remove this from config if you simply want to bind with your username.
-
"BaseDN": "dc=example,dc=com" (Required) This is the BaseDN for the ldap domain, this is required.
-
"Filter": "(&(objectCategory=person)(objectClass=user)(samAccountName=%s))" (Required) You can use a different filter to search for user to authenticate. This field is required.
-
"MemberSearchAttribute": "memberOf" (Required) Attribue by which group membership is found in ldap, most of the time its simply "memberOf" or "ismemberOf". This field is required.
-
"GroupRoles" (Required) Group roles defines what permission this group has on the k8s API. For example, "GroupRoles": {"group1": ["admin"], "group2": ["read"]} will give members of group1 admin privileges (Read/Write/Delete) on all resources and verbs on your k8s cluster. Whereas members of group2 will only have read - List/Watch - privileges.
-
"UserRoles" (Optional) User roles can override group roles. If you have user within a group that needs more privilege than the rest of the group you can define it here. You can also restrict access to a specific user(s) with the same logic.
Use your cluster deployment tool to achieve the following or add the following fields to your k8s api server:
Authentication - is driven by 2 flags, namely:
--authentication-token-webhook-config-file
--authentication-token-webhook-cache-ttl
Add the following to your k8s-api manifest, pointing webhook-config-file to a yaml with the following content:
# Filename: webhook-authn-config.yaml
# clusters refers to the remote service.
clusters:
- name: webhook-token-auth-cluster
cluster:
server: https://localhost:9191/authenticate
insecure-skip-tls-verify: true
# users refers to the API server's webhook configuration.
users:
- name: webhook-token-auth-user
current-context: webhook-token-auth
contexts:
- context:
cluster: webhook-token-auth-cluster
user: webhook-token-auth-user
name: webhook-token-auth
So your api-server configuration should consist of the following:
--authentication-token-webhook-config-file=webhook-authn-config.yaml
--authentication-token-webhook-cache-ttl=5m0s
Authorisation, similarly, is controlled by the following flags:
--authorization-webhook-config-file
--authorization-mode=Node,RBAC,Webhook
Add the follow lines to your api-server manifest, with authorization-webhook-config-file pointing to a yaml with the follwing content:
# Filename: webhook-authz-config.yaml
# clusters refers to the remote service.
clusters:
- name: webhook-token-authz-cluster
cluster:
server: https://localhost:9191/authorize
insecure-skip-tls-verify: true
# users refers to the API server's webhook configuration.
users:
- name: webhook-token-authz-user
current-context: webhook-token-authz
contexts:
- context:
cluster: webhook-token-authz-cluster
user: webhook-token-authz-user
name: webhook-token-authz
So, your server-api configuration should consist of line that look similar to:
--authorization-webhook-config-file=webhook-authz-config.yaml
--authorization-mode=Node,RBAC,Webhook
At this point, you can look at both api-server logs, and k8s-ldap logs to see authentication and authorisation request getting process though the webhook middleware.