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

[YCQL] Cassandra user gets regenerated after restart #21057

Open
yugabyte-ci opened this issue Feb 14, 2024 · 0 comments
Open

[YCQL] Cassandra user gets regenerated after restart #21057

yugabyte-ci opened this issue Feb 14, 2024 · 0 comments
Labels
area/ycql Yugabyte CQL (YCQL) jira-originated kind/bug This issue is a bug priority/high High Priority status/awaiting-triage Issue awaiting triage

Comments

@yugabyte-ci
Copy link
Contributor

yugabyte-ci commented Feb 14, 2024

Jira Link: DB-10024

@yugabyte-ci 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
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 status/awaiting-triage Issue awaiting triage
Projects
None yet
Development

No branches or pull requests

1 participant