-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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
[YCQL] Support deletion of Cassandra user #21057
Labels
area/ycql
Yugabyte CQL (YCQL)
jira-originated
kind/bug
This issue is a bug
priority/high
High Priority
Comments
yugabyte-ci
added
area/ycql
Yugabyte CQL (YCQL)
jira-originated
kind/bug
This issue is a bug
priority/high
High Priority
status/awaiting-triage
Issue awaiting triage
labels
Feb 14, 2024
swapshivam3
added a commit
that referenced
this issue
Apr 11, 2024
Summary: Customer wanted to delete the cassandra role in YCQLsh for specific use case of using their own LDAP server and did not want to share the cassandra role among different clusters as they were using a single server. But once the cassandra role has been dropped (through another superuser) in YCQLsh, if the cluster is restarted, the role gets regenerated again with the **default** password, as the code currently only scans if the role exists or not, and if it doesn't, it creates the default role. **Solution** To solve this, added a boolean flag in SysSecurityConfigEntryPB called cassandra_user_created to mark if the role has been created in the past. If that is true, we don't create the role anymore. **Limitation** For upgrading a cluster, this change would need a restart for the changes to come into effect after the autoflag is promoted as the cassandra role is checked at cluster startup time. After promoting autoflag and restarting again, it will be possible to delete the cassandra role without it being regenerated. **Upgrade/Rollback safety:** The change is protected by the autoflag **ycql_allow_cassandra_drop**, for upgrading the cluster user would need to use yb-admin promote_auto_flags and restart after changing the version so that new change comes into effect. Jira: DB-10024 Test Plan: **./yb_build.sh release --java-test 'org.yb.cql.TestRoles'** Manual Testing Tested cases involving 1. Creating a new cluster (Autoflag true by default) 2. Restarting a new cluster (Autoflag true by default) 3. Restarting a new cluster with deleted cassandra role (Autoflag true by default) 4. Upgrading an existing cluster (Upgrade, promote autoflag, restart again) 5. Upgrading an existing cluster with deleted cassandra role (Upgrade, promote autoflag, restart again) Reviewers: skumar, loginov, stiwary Reviewed By: skumar, stiwary Subscribers: ybase, yql, bogdan Differential Revision: https://phorge.dev.yugabyte.com/D32558
swapshivam3
added a commit
that referenced
this issue
Apr 18, 2024
…letion Summary: Original commit: 53afa97 / D32558 Customer wanted to delete the cassandra role in YCQLsh for specific use case of using their own LDAP server and did not want to share the cassandra role among different clusters as they were using a single server. But once the cassandra role has been dropped (through another superuser) in YCQLsh, if the cluster is restarted, the role gets regenerated again with the **default** password, as the code currently only scans if the role exists or not, and if it doesn't, it creates the default role. **Solution** To solve this, added a boolean flag in SysSecurityConfigEntryPB called cassandra_user_created to mark if the role has been created in the past. If that is true, we don't create the role anymore. **Limitation** For upgrading a cluster, this change would need a restart for the changes to come into effect after the autoflag is promoted as the cassandra role is checked at cluster startup time. After promoting autoflag and restarting again, it will be possible to delete the cassandra role without it being regenerated. **Upgrade/Rollback safety:** The change is protected by the autoflag **ycql_allow_cassandra_drop**, for upgrading the cluster user would need to use yb-admin promote_auto_flags and restart after changing the version so that new change comes into effect. Jira: DB-10024 Test Plan: **./yb_build.sh release --java-test 'org.yb.cql.TestRoles'** Manual Testing Tested cases involving 1. Creating a new cluster (Autoflag true by default) 2. Restarting a new cluster (Autoflag true by default) 3. Restarting a new cluster with deleted cassandra role (Autoflag true by default) 4. Upgrading an existing cluster (Upgrade, promote autoflag, restart again) 5. Upgrading an existing cluster with deleted cassandra role (Upgrade, promote autoflag, restart again) Reviewers: skumar, loginov, stiwary Reviewed By: skumar Subscribers: ybase, yql, bogdan Tags: #jenkins-ready Differential Revision: https://phorge.dev.yugabyte.com/D34016
swapshivam3
added a commit
that referenced
this issue
Apr 18, 2024
…tion Summary: Original commit: 53afa97 / D32558 Customer wanted to delete the cassandra role in YCQLsh for specific use case of using their own LDAP server and did not want to share the cassandra role among different clusters as they were using a single server. But once the cassandra role has been dropped (through another superuser) in YCQLsh, if the cluster is restarted, the role gets regenerated again with the **default** password, as the code currently only scans if the role exists or not, and if it doesn't, it creates the default role. **Solution** To solve this, added a boolean flag in SysSecurityConfigEntryPB called cassandra_user_created to mark if the role has been created in the past. If that is true, we don't create the role anymore. **Limitation** For upgrading a cluster, this change would need a restart for the changes to come into effect after the autoflag is promoted as the cassandra role is checked at cluster startup time. After promoting autoflag and restarting again, it will be possible to delete the cassandra role without it being regenerated. **Upgrade/Rollback safety:** The change is protected by the autoflag **ycql_allow_cassandra_drop**, for upgrading the cluster user would need to use yb-admin promote_auto_flags and restart after changing the version so that new change comes into effect. Jira: DB-10024 Test Plan: **./yb_build.sh release --java-test 'org.yb.cql.TestRoles'** Manual Testing Tested cases involving 1. Creating a new cluster (Autoflag true by default) 2. Restarting a new cluster (Autoflag true by default) 3. Restarting a new cluster with deleted cassandra role (Autoflag true by default) 4. Upgrading an existing cluster (Upgrade, promote autoflag, restart again) 5. Upgrading an existing cluster with deleted cassandra role (Upgrade, promote autoflag, restart again) Reviewers: skumar, loginov, stiwary Reviewed By: skumar Subscribers: ybase, yql, bogdan Tags: #jenkins-ready Differential Revision: https://phorge.dev.yugabyte.com/D34015
swapshivam3
added a commit
that referenced
this issue
Apr 18, 2024
…tion Summary: Original commit: 53afa97 / D32558 Customer wanted to delete the cassandra role in YCQLsh for specific use case of using their own LDAP server and did not want to share the cassandra role among different clusters as they were using a single server. But once the cassandra role has been dropped (through another superuser) in YCQLsh, if the cluster is restarted, the role gets regenerated again with the **default** password, as the code currently only scans if the role exists or not, and if it doesn't, it creates the default role. **Solution** To solve this, added a boolean flag in SysSecurityConfigEntryPB called cassandra_user_created to mark if the role has been created in the past. If that is true, we don't create the role anymore. **Limitation** For upgrading a cluster, this change would need a restart for the changes to come into effect after the autoflag is promoted as the cassandra role is checked at cluster startup time. After promoting autoflag and restarting again, it will be possible to delete the cassandra role without it being regenerated. **Upgrade/Rollback safety:** The change is protected by the autoflag **ycql_allow_cassandra_drop**, for upgrading the cluster user would need to use yb-admin promote_auto_flags and restart after changing the version so that new change comes into effect. Jira: DB-10024 Test Plan: **./yb_build.sh release --java-test 'org.yb.cql.TestRoles'** Manual Testing Tested cases involving 1. Creating a new cluster (Autoflag true by default) 2. Restarting a new cluster (Autoflag true by default) 3. Restarting a new cluster with deleted cassandra role (Autoflag true by default) 4. Upgrading an existing cluster (Upgrade, promote autoflag, restart again) 5. Upgrading an existing cluster with deleted cassandra role (Upgrade, promote autoflag, restart again) Reviewers: skumar, loginov, stiwary Reviewed By: skumar Subscribers: bogdan, yql, ybase Tags: #jenkins-ready Differential Revision: https://phorge.dev.yugabyte.com/D34014
yugabyte-ci
changed the title
[YCQL] Cassandra user gets regenerated after restart
[YCQL] Support deletion of Cassandra user
Aug 16, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
area/ycql
Yugabyte CQL (YCQL)
jira-originated
kind/bug
This issue is a bug
priority/high
High Priority
Jira Link: DB-10024
The text was updated successfully, but these errors were encountered: