...

The following KRL declaration would bind the entire map associate associated with the twitter key to the variable my_key:

...

KRL provides a mechanism for storing accessing keys that are stored in modules that can only be accessed by named rulesets. A key module uses the pragma provide keys to keys (or provides keys) to specify which previously defined keys should be made available to which rulesets. For example, is rulesets a16x175 and b16x77 require the use of a set of Dropbox keys, the following module could provide those keys specifically to the named rulesets:

...

ruleset a16x175 {
  meta {
    name "Dropbox module test"
    use module b16x5 
    use module b16x0 alias dropbox with
         app_key = keys:dropbox('"app_key'") and	   
         app_secret = keys:dropbox('"app_secret'")
  }

This example loads the keys in module b16x5 and then uses them to configure module b16x0.  

Security Considerations

KRE tries to ensure that key values are not disclosed outside of your program. Therefore, you should be careful binding key values to variables since those values may be exposed in logging statements or any generated JavaScript. 

When using key modules as shown above, you will need your any key rulesets to be available on a URL so that you can register them with the rules engine. Otherwise they will not be available for use by other rulesets. The URL should be protected so that it is they are not publicly viewable. For example, the ruleset could be on a WebDAV server with an appropriately formatted BASIC AUTH URL or in a private Github repositoryprivate repository. 

If you're hosting on AWS S3, be sure to check the permissions of the file so that it is not writable or readable by anyone other than authorized users. You will need to create a pre-signed AWS URL. There are ways of doing this with various programming languages. I've found this project for signing AWS URLs with a Bash script to be quite useful. 

...