anchor.diff:  * API Secret: `some_secret_for_shakti`
   * Click on the `Create tenant` to also create the tenant in Kill Bill.
   
  -At this point the tenant exists in Kill Bill and is known from KAUI as well.
  +At this point, the tenant exists in Kill Bill and is known from KAUI as well.
   
   We can then configure the allowed users. KAUI needs to know who can access which tenant, and this information is kept in the KAUI database.
   It really means that any user known from Kill Bill (shiro.ini) will be able to make API calls against any tenant provided the user specifies the correct tenant `api_key` and `api_secret`, so the security resides behind keeping those keys secret.
  
positive.code: ----
  
  
  Finally since we run the analytics plugin, we need to configure the analytics tables.
  There is a script that can be run to configure the analytics tables with all the existing views and reports.
  The script needs to be run from the https://github.com/killbill/killbill-analytics-plugin[analytics repo], and it will both hit some endpoints on the running instance of killbill and also create some views through mysql client.
  If your RDS instance is not visible to the public world, you have two options
  
negative.code: 
  === Scenario
  
  In this tutorial, we will look at how one could leverage the multi-tenancy feature from Kill Bill. The scenario we will describe, is one where we would like to provide 'Subscription As A Service' (SaaS) in the cloud (AWS). The tutorial will skip all the operational good practices such as redundancy of instances, firewalls, load balancers and focus instead on the Kill Bill specifics. Also, note that when deploying in the cloud where instances can come and go, the https://github.com/killbill/killbill/wiki/Kill-Bill-Notification-Configuration[configuration of the bus and notifications queues] need to be understood.
  
  
  We will assume that we only need one plugin to make the payments, and as an example we will use the Stripe plugin.
  
  
  === Users and Roles
  
  Let's start by defining some users and roles:
  
  * The user setting up the `Subscription As A Service` in the cloud, is called *superadmin*, and will have all the privileges to configure the tenants and setup the roles associated with the other users.
  * The admin user associated to each tenant will be called `admin_X` where `X` is the name of the tenant.
  