With role-based security, you specify in the role configuration which indices a role can access. So if you have RoleA which can access .kibana-a; and RoleB that can access .kibana-b; RoleA can not access .kibana-b and RoleB can not access .kibana-a. Create an instance of Kibana configured to use .kibana-a as its index and create a role that has access to manage, read, index and delete privilege to .kibana-a (as well as cluster monitor privilege) - those are all the privileges that the built-in kibana_user role has. Then create some users with RoleA role, and give those users the URL to the KibanaA instance. Those users will not be able to see any of the data contained in the .kibana-b index. So the idea is just to make 2 duplicates of the built-in kibana_user role but customize the index they can access.
The .kibana indices manage the index patterns, saved searches, visualizations, dashboards and advanced settings for Kibana. The data in the dashboards comes from other indices such as Logstash or Beats, and the logged-in users will need privilege to access that as well. The data will be protected by default and you can grant access to the data using different kinds of roles. Users can have as many roles added as you like.
Of course, you could do all this without security - just create 2 different instances of Kibana that use different .kibana indices. The data will be accessible if users know how to find it, but users will only see dashboards in the listing and other saved objects that are configured for their own instance. That was the first part of my initial answer. I added the second part of my answer, which really just extends the first part, because you expressed interest in knowing what you can do with X-Pack security.
Hope that clears it up,
-Tim