-
Notifications
You must be signed in to change notification settings - Fork 116
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Add a possibility to add custom roles definitions for julieops (#336)
* initial step into adding custom roles for julieops * add test and wire up transformations and actions for having custom role definitions in acls and rbac providers * add integration test for rbac * add connector level test for rbac * add sample actions and tests for ksqldb * simplify acl conversion * add early validation for wrong ACLs config values * add sample documentation page * ammend rbac julieroles test to make it more repetable * make role and operation be an alias
- Loading branch information
Showing
32 changed files
with
1,175 additions
and
13 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,128 @@ | ||
Define custom roles for JulieOps | ||
******************************* | ||
|
||
While JulieOps offer you as a user the possibility to manage the ACLs (and RBAC if you're using the Confluent Platform) for most common | ||
applications deployments such as Consumers, Producers, Kafka Streams, Connectors and ksqlDB, it would be for some cases amazing to be | ||
be able to keep using the powerful abstractions of JulieOps but provide your own set of ACLs. | ||
|
||
For example: | ||
|
||
* If you are deploying a custom App and aim to give application specific roles | ||
* Deploying applications that might not fit our of the box with generic permissions provided by JulieOps | ||
* Or just if you are building your own roles based on Simple ACLs or Confluent RBAC | ||
|
||
and more. | ||
|
||
But, how can you get this with JulieOps. | ||
|
||
Defining the your roles | ||
----------- | ||
|
||
First thing is to define your roles in a configuration file, this file should look like this: | ||
|
||
.. code-block:: YAML | ||
roles: | ||
- name: "app" | ||
acls: | ||
- resourceType: "Topic" | ||
resourceName: "{{topic}}" | ||
patternType: "PREFIXED" | ||
host: "*" | ||
operation: "ALL" | ||
permissionType: "ALLOW" | ||
- resourceType: "Topic" | ||
resourceName: "sourceTopic" | ||
patternType: "LITERAL" | ||
host: "*" | ||
operation: "ALL" | ||
permissionType: "READ" | ||
- resourceType: "Topic" | ||
resourceName: "targetTopic" | ||
patternType: "LITERAL" | ||
host: "*" | ||
operation: "ALL" | ||
permissionType: "WRITE" | ||
- resourceType: "Group" | ||
resourceName: "{{group}}" | ||
patternType: "PREFIXED" | ||
host: "*" | ||
operation: "READ" | ||
permissionType: "ALLOW" | ||
if you are using Confluent Platform RBAC functionality to define your own Access Control management, the only different property | ||
per acl is **role**, so the file might look like this: | ||
|
||
.. code-block:: YAML | ||
roles: | ||
- name: "app" | ||
acls: | ||
- resourceType: "Topic" | ||
resourceName: "{{topic}}" | ||
patternType: "PREFIXED" | ||
host: "*" | ||
role: "ResourceOwner" | ||
- resourceType: "Topic" | ||
resourceName: "sourceTopic" | ||
patternType: "LITERAL" | ||
host: "*" | ||
role: "DeveloperRead" | ||
- resourceType: "Topic" | ||
resourceName: "targetTopic" | ||
patternType: "LITERAL" | ||
host: "*" | ||
role: "DeveloperWrite" | ||
- resourceType: "Group" | ||
resourceName: "{{group}}" | ||
patternType: "PREFIXED" | ||
host: "*" | ||
role: "DeveloperRead" | ||
- resourceType: "Subject" | ||
resourceName: "Subject:foo" | ||
patternType: "LITERAL" | ||
host: "*" | ||
role: "DeveloperRead" | ||
- resourceType: "Connector" | ||
resourceName: "Connector:con" | ||
patternType: "LITERAL" | ||
host: "*" | ||
role: "SecurityAdmin" | ||
- resourceType: "KsqlCluster" | ||
resourceName: "KsqlCluster:ksql-cluster" | ||
patternType: "LITERAL" | ||
host: "*" | ||
role: "ResourceOwner" | ||
Plug this into JulieOps | ||
----------- | ||
|
||
Once the roles are define, the only thing you need to do is to configure your deployment to use it. This can be done using this | ||
configuration variable in your property file: | ||
|
||
|
||
.. code-block:: JAVA | ||
julie.roles=/path/to/the/roles/file | ||
How would my new topology file look like | ||
----------- | ||
|
||
Once the new roles are setup, your topology can start using them just as the previous "hardcoded" roles. | ||
Your topology file could look like this: | ||
|
||
|
||
.. code-block:: YAML | ||
context: "contextOrg" | ||
source: "source" | ||
projects: | ||
- name: "foo" | ||
foo: | ||
- principal: "User:banana" | ||
group: "foo" | ||
bar: | ||
- principal: "User:bandana" | ||
group: "bar" |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,31 @@ | ||
--- | ||
roles: | ||
rules: | ||
- name: "security" | ||
acls: | ||
- resourceType: "Topic" | ||
resourceName: "{{topic}}" | ||
patternType: "" | ||
host: "" | ||
operation: "" | ||
permissionType: "" | ||
- resourceType: "Group" | ||
resourceName: "{{group}}" | ||
patternType: "" | ||
host: "" | ||
operation: "" | ||
permissionType: "" | ||
- name: "other" | ||
acls: | ||
- resourceType: "Topic" | ||
resourceName: "" | ||
patternType: "" | ||
host: "" | ||
operation: "" | ||
permissionType: "" | ||
- resourceType: "Group" | ||
resourceName: "" | ||
patternType: "" | ||
host: "" | ||
operation: "" | ||
permissionType: "" |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.