Automate functional Security tests

[elasticmachine]

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]

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]

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]

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]

Original comment by @Rasroh:

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

[elasticmachine]

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.

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.

• Create a user customer1 with viewssnrole

• Create a user customer2 with viewnossnrole

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

• 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.

[elasticmachine]

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]

Original comment by @LeeDr:

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

[elasticmachine]

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

[tsullivan]

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

[LeeDr]

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