WHAT

There is a defect in access management functionality.  The impact of the defect will be user confusion about the state of the system.  There is no unintended privilege escalation.

The defect occurs if the users of a kafka instance follows these steps.  

1. User A creates kafka instance
2. User A (who is the owner), adds permissions for user B
3. User A transfers ownership to user B

The transfer of ownership will mean that the static owner rules will apply to B.  The ACL database (zookeeper) will however still contain 'orphan' rules for user B, left behind from step 2.  The RHOSAK authorizer will never actually consider the orphan because of the action of io.bf2.kafka.authorizer.CustomAclAuthorizer#delegateOrDeny, but the presence of the rules could mislead a user trying to reason about behaviour.

The defect should be fixed.

WHY

Defect will cause users to be confused about the ACL rules that are in force.

HOW

The kafka instance is not really aware of ownership change. The broker's are merely restarted with a different ACL configuration so they have no idea that the owner is different to what was previously the case.

One possible solution: introduce another step in the CustomAclAuthorizer#configure() method that is charged with removing any acl rules in the database (zookeeper) belonging to any of the aclPrincipals. This would remove any orphans.

DONE

• Supporting unit tests added.
• Consider extending the end to end test suite. Existing owner change tests exist already
  io.managed.services.test.kafka.KafkaAccessMgmtTest#testAdminUserCanChangeTheKafkaInstanceOwner