Cookbook/AuthenticationAndAccessControl

From Kx Wiki
Jump to: navigation, search

The wiki is moving to a new format and this page is no longer maintained. You can find the new page at code.kx.com/q/cookbook/authentication.

The wiki will remain in place until the migration is complete. If you prefer the wiki to the new format, please tell the Librarian why.

Authentication And Access Control

kdb+ has built-in authentication via the [[1]]-u/-U command line options

kdb+ Access Control is very flexible, through hooking the msg interface - .z.pg, .z.ps, and validating the input before execution.

e.g.

q)allowedFns:(`func1;`func2;`func3;+;-) / list of allowed function/ops to call
q)checkFn:{if[not x in allowedFns;'(-3!x)," not allowed"];}
q)validatePT:{if[0h=t:type x;if[(not 0h=type first x)&1=count first x;checkFn first x;];.z.s each x where 0h=type each x;];}
q).z.pg:{if[10h=type x;x:parse x;];validatePT x;eval x}

q)checkFn[+]
q)checkFn[*]
'not allowed
q)validatePT parse"func1[2+3]"

Beware that ticker plants, and other high volume msg sources such as feed handlers, will most likely be inserting data via .z.ps and to cater for such high volumes, the handles of those processes should be used to avoid the overhead of these validation checks. i.e. feeds and tickerplants could be viewed as trusted processes.

Typically, client processes connect to a gateway, and execute canned functions on that gateway, which in turn issues queries to rdbs and hdbs, joining and returning data to the client. Hence the gateways can have open access, restricted by ip, user, and validation checks. Rdbs/hdbs could then be closed access, restricted by ip address/user only.

This can easily be extended to group/role permissioning.

see #dotz, Using Modified .z Functions for some concrete examples (controlaccess.q)

Personal tools
Namespaces
Variants
Actions
Navigation
Print/export
Toolbox