Initializing Kadeck with roles and groups through files

Initializing Kadeck with roles and groups through files

Kadeck allows initialization of roles and groups through YAML configuration files using environment variables:

  1. xeotek_kadeck_init_roles_file: Path to roles configuration file
  2. xeotek_kadeck_init_groups_file: Path to groups configuration file

Warning
Existing roles, groups and user-group assignments will be cleared before loading new configurations on each startup.

Prerequisites

This feature requires LDAP or OpenID Connect synchronization enabled. User-group assignments must be managed through these external authentication services, as manual group management within Kadeck is not supported for this feature.

File Structure

roles.yaml

  1. - name: "Role Name"
  2.   description: "Role Description"
  3.   rights:
  4.     - action: "Permission Action"
  5.       resource: "Resource Pattern"
  6.       effect: "Allow"

groups.yaml

  1. - name: "Group Name"
  2.   externalMapping: "Ext. Directory Service Group Name"
  3.   description: "Group Description" 
  4.   roles:
  5.     - "Role Name"

Configuration Example


1. Create role definitions:
  1. - name: "Finance Team Role"
  2.   description: "Full topic-related access for all topics with the prefix finance on cluster 1"
  3.   rights:
  4.     - action: "TopicAccessAll"
  5.       resource: "1:finance*"
  6.       effect: "Allow"

2. Create group definitions with external mappings matching your LDAP/OpenID groups:
  1. - name: "Finance Team QA"
  2.   externalMapping: "us-finance-department-quality"
  3.   description: "The finance QA team"
  4.   roles:
  5.     - "Finance Team Role"

3. Set environment variables:
  1. export xeotek_kadeck_init_roles_file=/path/to/roles.yaml
  2. export xeotek_kadeck_init_groups_file=/path/to/groups.yaml

Important Notes

- Requires LDAP or OpenID Connect synchronization
- User-group assignments are managed through external authentication services
- Existing roles and groups will be cleared before loading new configurations (on each startup!)
- Role names referenced in groups.yaml must match names defined in roles.yaml
- Resource patterns support wildcards (*) for broader access control