Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Automate functional Security tests #17906

Closed
3 of 9 tasks
elasticmachine opened this issue Feb 10, 2017 · 10 comments
Closed
3 of 9 tasks

Automate functional Security tests #17906

elasticmachine opened this issue Feb 10, 2017 · 10 comments
Assignees
Labels
Feature:Kibana Management Feature label for Data Views, Advanced Setting, Saved Object management pages Feature:Users/Roles/API Keys impact:needs-assessment Product and/or Engineering needs to evaluate the impact of the change. test tests_needed

Comments

@elasticmachine
Copy link
Contributor

Original comment by @LeeDr:

Our Security plugin is a significant component of our commercial offering and critical to many customer deployments. We need to have thorough security use cases and automated tests of those use cases.

The bare minimum we should have are the most common positive test cases;

  • As the built-in 'elastic' superuser, create a role 'logstash' with the minimum privileges to give access to an index in Kibana. Create a new user 'userl' with that new role and 'kibana_user' role. Make sure that user can log in, create an index pattern for that index (logstash, for example), delete the index pattern, and save a search in Kibana. (this was a 5.4.0 regression)
  • As the built-in 'elastic' superuser, create a new user 'userm' with monitoring role. Make sure that user can log in and use Monitoring.
  • Create a user with security management role. Make sure they can create and delete users and roles.
  • Create an 'admin' superuser. Make sure they can create and delete index patterns and save objects in Kibana. Make sure they can use Monitoring. Make sure they can manage other users, including changing the password of the built-in 'elastic' user.

Next we should automate the negative test cases such as;

  • A user who does not have monitoring role, should get a message when they try to go to the monitoring app.
  • A user who does not have kibana_user role should not be able to create and delete index patterns, and should not have access to data.?
  • A user who does not have 'logstash' role should not be able to read data from that index.

Customers have also asked about giving users some level of restricted access to Kibana. For example;

  • Can we create a kibana_read role that allows access to Kibana and saved objects but does not let them save new objects or delete existing objects? I think it's possibly but with ugly errors on screen when they attempt the actions they don't have privileges for.
  • Use cases for document level security.
@elasticmachine
Copy link
Contributor Author

Original comment by @LeeDr:

@lukasolson I'm hoping you have some time to work on this in the integration-test repo. I got started on it here but needs to move into x-plugins I think.

#7690

@elasticmachine
Copy link
Contributor Author

Original comment by @LeeDr:

I'm helping @Rasroh implement some doc level security and field level security tests in the integration-test repo which can move to x-plugins once we have the framework set up.

@elasticmachine
Copy link
Contributor Author

Original comment by @Rasroh:

Here are the steps I plan to accomplish to cover Document Level Security Test

  • Index two simple documents into one index.
    a) This creates a document for EAST region
PUT myindex/mytype/1
{
  "name" : "ABC Company",
  "region" : "EAST"
}

b) This creates a document for WEST region.

PUT myindex/mytype/2
{
  "name" : "DEF Company",
  "region" : "WEST"
}
  • You can verify the index data using:
GET myindex/mytype/_search
  • Create a default index pattern in Kibana called dlstest
  • Create Roles
    a) This creates a role that will have access to only the EAST region:
POST /_shield/role/myroleEAST
{
  "indices": [ 
    {
      "names": [ ".kibana*"],
      "privileges": ["all"]
    },
    {
      "names": [ "myindex*" ], 
      "privileges": [ "read", "view_index_metadata" ],
      "query": "{\"match\": {\"region\": \"EAST\"}}"
    }
  ]
}

b) Create a role that will have access to only WEST region.

POST /_shield/role/myroleWEST
{
  "indices": [ 
    {
      "names": [ ".kibana*"],
      "privileges": ["all"]
    },
    {
      "names": [ "myindex*", "view_index_metadata" ], 
      "privileges": ["read"],
      "query": "{\"match\": {\"region\": \"WEST\"}}"
    }
  ]
}
  • GET /_shield/role
  • Create Users - myuserEAST- who has access to EAST region, myuserWEST 2 - who has access to WEST region
    a Manager- who has access to both EAST and WEST region.
  • myuserEAST
POST /_shield/user/myuserEAST
{
  "password" : "mypassword", 
  "roles" : [ "myroleEAST" ]
}
  • myuserWEST
POST /_shield/user/myuserWEST
{
  "password" : "mypassword", 
  "roles" : [ "myroleWEST" ]
}
  • myuserManager
POST /_shield/user/myuserManager
{
  "password" : "mypassword", 
  "roles" : [ "myroleEAST","myroleWEST" ]
}

TEST:

  • Login as myuserEAST and verify he sees only EAST index.
  • Login as myuserWEST and verify he sees only WEST index
  • Login as myuserManager and verify he sees both EAST and WEST indices.

@elasticmachine
Copy link
Contributor Author

Original comment by @Rasroh:

All of the above steps will be using Kibana UI ( instead of API driven)

@elasticmachine
Copy link
Contributor Author

Original comment by @Rasroh:

Field Level Security Test : ( automation test scenario)

  • Index two simple documents into one index.
    a) This creates a document with the following fields - customer name, customer region and customer ssn
PUT customerindex/customertype/1
{
  "customer_name" : "ABC Company",
  "customer_region" : "EAST",
   "customer_ssn"   :   "111.222.3333"
}
PUT customerindex/customertype/2
{
  "customer_name" : "DEF Company",
  "customer_region" : "WEST",
  "customer_ssn" : "444.555.6666"
}

  • Create an index pattern in Kibana called customerindex

  • Create Roles to access the specific fields that each role can access in the role definition. :
    a ) Create a FLS role called viewssnrolewhich has access to your index pattern created with specific priviliges such as view_index_metadata, readand has access to customer_ssn,customer_region, customer_namefields in thegranted fieldssection. It should also have access tokibana*` index pattern and grant (*) all privileges.

screen shot 2016-12-12 at 7 46 31 pm

b) Create another FLS role called viewnossnrole which has access to your index pattern created with specific privileges such as view_index_metadata ,read and Granted Fields to view are customer_region, customer_name. Notice this role has no access to customer_ssn field.
Hence any user associated with this specific viewnossnrole should NOT see customer_ssn field . Which means that this field is secured field and the user has no access to it.

screen shot 2016-12-12 at 7 46 47 pm

  • Create a user customer1 with viewssnrole

screen shot 2016-12-12 at 7 45 54 pm

  • Create a user customer2 with viewnossnrole

screen shot 2016-12-12 at 7 46 09 pm

Test:

  • Login as customer1 and navigate to Discover tab and notice that for your index pattern selected, customer1 is able to view all the fields - including customer_ssn as shown

screen shot 2016-12-12 at 7 44 53 pm

  • Login as customer2 and navigate to Discover tab and notice that for your index pattern selected customer2 is able to view all the fields except customer_ssn field as he has no access to it.

screen shot 2016-12-12 at 7 45 28 pm

@elasticmachine
Copy link
Contributor Author

Original comment by @LeeDr:

@Rasroh

  1. Instead of creating roles that combine customer* access and .kibana* access, I think the new role should only have customer* index access and the new users would get that role plus kibana_user role (our automation can't do the multiple indexes right now anyway)
  2. customerindex is the index but then says customerdata is the index pattern. They should be the same or customer* works
  3. there are several differences in the granted fields. I think they are supposed to be the same except for the customer_ssn field

@elasticmachine
Copy link
Contributor Author

Original comment by @LeeDr:

Add a test to catch issues like this where a non-superuser couldn't create an index pattern;
LINK REDACTED

@timroes timroes added Team:Visualizations Visualization editors, elastic-charts and infrastructure Feature:Kibana Management Feature label for Data Views, Advanced Setting, Saved Object management pages and removed :Management DO NOT USE labels Nov 27, 2018
@flash1293 flash1293 added Team:AppServicesSv and removed Team:Visualizations Visualization editors, elastic-charts and infrastructure labels Nov 19, 2021
@elasticmachine
Copy link
Contributor Author

Pinging @elastic/kibana-app-services (Team:AppServicesSv)

@exalate-issue-sync exalate-issue-sync bot added impact:needs-assessment Product and/or Engineering needs to evaluate the impact of the change. loe:small Small Level of Effort labels Feb 1, 2022
@exalate-issue-sync exalate-issue-sync bot removed the loe:small Small Level of Effort label Mar 18, 2022
@tsullivan
Copy link
Member

@LeeDr Checking in on this old issue. Is it still needed?

@LeeDr
Copy link

LeeDr commented Apr 20, 2022

I think it's safe to close this now in favor of this meta issue #60815

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Feature:Kibana Management Feature label for Data Views, Advanced Setting, Saved Object management pages Feature:Users/Roles/API Keys impact:needs-assessment Product and/or Engineering needs to evaluate the impact of the change. test tests_needed
Projects
None yet
Development

No branches or pull requests

6 participants