jonmeredith commented on code in PR #2372: URL: https://github.com/apache/cassandra/pull/2372#discussion_r1276537076
########## doc/modules/cassandra/pages/getting-started/mtlsauthenticators.adoc: ########## @@ -0,0 +1,133 @@ += Getting started with mTLS authenticators + +When a certificate based authentication protocol like TLS is used for client and +Internode connections, `MutualTlsAuthenticator` & `MutualTlsInternodeAuthenticator` +can be used for the authentication by leveraging the client certificates from the +SSL handshake. + +After SSL handshake, identity from the client certificates is extracted and only +authorized users will be granted access. + +== What is an Identity + +One can define their own identity for certificates by extracting some fields or Review Comment: ```suggestion Operators can define their own identity for certificates by extracting some fields or ``` ########## doc/modules/cassandra/pages/getting-started/mtlsauthenticators.adoc: ########## @@ -0,0 +1,133 @@ += Getting started with mTLS authenticators + +When a certificate based authentication protocol like TLS is used for client and +Internode connections, `MutualTlsAuthenticator` & `MutualTlsInternodeAuthenticator` +can be used for the authentication by leveraging the client certificates from the +SSL handshake. + +After SSL handshake, identity from the client certificates is extracted and only +authorized users will be granted access. + +== What is an Identity + +One can define their own identity for certificates by extracting some fields or +information from the certificates. one can implement the interface `MutualTlsCertificateValidator` +to provide logic for validating & extracting identity from the certificates. Review Comment: ```suggestion information from the certificates. Implementing the interface `MutualTlsCertificateValidator` supports validating & extracting identity from the certificates that can be used by `MutualTlsAuthenticator` and `MutualTlsInternodeAuthenticator` to customize for the certificate conventions used in the deployment environment. ``` ########## doc/modules/cassandra/pages/developing/cql/cql_singlefile.adoc: ########## @@ -2235,6 +2235,57 @@ LIST ROLES; but only roles with the `LOGIN` privilege are included in the output. +[[databaseIdentity]] +=== Database Identities + +[[AddIdentityStmt]] +==== ADD IDENTITY + +_Syntax:_ + +bc(syntax).. + +::= ADD IDENTITY ( IF NOT EXISTS )? TO ROLE ? + +_Sample:_ + +bc(sample). + +ADD IDENTITY 'id1' TO ROLE 'role1'; + +Only a user with previleges to add roles can add identities + +Role names & Identity names should be quoted if they contain non-alphanumeric characters. + +[[addIdentityConditional]] +===== Adding an identity conditionally + +Attempting to add an existing identity results in an invalid query +condition unless the `IF NOT EXISTS` option is used. If the option is +used and the identity exists, the statement is a no-op. + +bc(sample). + +ADD IDENTITY IF NOT EXISTS 'id1' TO ROLE 'role1'; + +[[dropIdentityStmt]] +==== DROP IDENTITY + +_Syntax:_ + +bc(syntax).. + +::= DROP IDENTITY ( IF EXISTS )? + +p. + +_Sample:_ + +bc(sample). + +DROP IDENTITY 'testIdentity'; + +DROP IDENTITY IF EXISTS 'testIdentity'; + +Only a user with previleges to drop roles can remove identities Review Comment: ```suggestion Only a user with privileges to drop roles can remove identities ``` ########## doc/modules/cassandra/pages/getting-started/mtlsauthenticators.adoc: ########## @@ -0,0 +1,133 @@ += Getting started with mTLS authenticators + +When a certificate based authentication protocol like TLS is used for client and +Internode connections, `MutualTlsAuthenticator` & `MutualTlsInternodeAuthenticator` +can be used for the authentication by leveraging the client certificates from the +SSL handshake. + +After SSL handshake, identity from the client certificates is extracted and only +authorized users will be granted access. + +== What is an Identity + +One can define their own identity for certificates by extracting some fields or +information from the certificates. one can implement the interface `MutualTlsCertificateValidator` +to provide logic for validating & extracting identity from the certificates. + +There is a default implementation of `MutualTlsCertificateValidator` with +https://spiffe.io/docs/latest/spiffe-about/spiffe-concepts/[SPIFFE] as the identity +of the certificates.This requires spiffe to be present in the SAN of the certificate. +One can implement their own validator that suits their needs. Review Comment: I'd just drop the `One can implement`...sentence as you already covered above. ########## doc/modules/cassandra/pages/getting-started/mtlsauthenticators.adoc: ########## @@ -0,0 +1,133 @@ += Getting started with mTLS authenticators + +When a certificate based authentication protocol like TLS is used for client and +Internode connections, `MutualTlsAuthenticator` & `MutualTlsInternodeAuthenticator` +can be used for the authentication by leveraging the client certificates from the +SSL handshake. + +After SSL handshake, identity from the client certificates is extracted and only +authorized users will be granted access. + +== What is an Identity + +One can define their own identity for certificates by extracting some fields or +information from the certificates. one can implement the interface `MutualTlsCertificateValidator` +to provide logic for validating & extracting identity from the certificates. + +There is a default implementation of `MutualTlsCertificateValidator` with +https://spiffe.io/docs/latest/spiffe-about/spiffe-concepts/[SPIFFE] as the identity +of the certificates.This requires spiffe to be present in the SAN of the certificate. +One can implement their own validator that suits their needs. + +For example, instead of using `SPIFFE` based validator a `CN` based validator can be +implemented. + +== Configuring mTLS authenticator for client connections + +Note that the following steps uses SPIFFE identity as an example, If you are using +a custom validator, use appropriate identity in place of `spiffe://testdomain.com/testIdentifier/testValue`. + +*STEP 1: Add authorized users to system_auth.identity_to_roles table* + +Note that only users with permissions to create/modify roles can add/remove identities. +Client certificates with the identities in this table will be trusted by C*. +[source, plaintext] +---- +ADD IDENTITY 'spiffe://testdomain.com/testIdentifier/testValue' TO ROLE 'read_only_user' +---- + +*STEP 2: Configure Cassandra.yaml with right properties* + +`client_encryption_options` configuration for mTLS connections +[source, plaintext] +---- +client_encryption_options: + enabled: true + optional: false + keystore: conf/.keystore + keystore_password: cassandra + truststore: conf/.truststore + truststore_password: cassandra + require_client_auth: false // to enable mTLS +---- +Configure mTLS authenticator and the validator for client connections . If you are +implementing a custom validator, use that instead of Spiffe validator +[source, plaintext] +---- +authenticator: + class_name : org.apache.cassandra.auth.MutualTlsAuthenticator + parameters : + validator_class_name: org.apache.cassandra.auth.SpiffeCertificateValidator +---- + +*STEP 3: Bounce the cluster* + +After the bounce, C* will accept mTLS connections from the clients and if their +identity is present in the `identity_to_roles` table, access will be granted. + +== Configuring mTLS authenticator for Internode connections + +Internode authenticator trusts certificates whose identities are present in +`internode_authenticator.parameters.trusted_peer_identities` if configured. + +Otherwise, it trusts connections which have the same identity as the node. +When a node is making an outbound connection to another node, it uses the +certificate configured in `server_encryption_options.outbound_keystore`. +During the start of the node, identity is extracted from the outbound keystore and +connections from other nodes who have the same identity will be trusted if +`trusted_peer_identities` is not configured. + +For example, if a node has `testIdentity` embedded in the certificate in +outbound keystore, It trusts connections from other nodes when their certificates +have `testIdentity` embedded in them. + +There is an optional configuration `node_identity` that can be used to verify identity +extracted from the keystore to avoid any configuration errors. + +*STEP 1: Configure server_encryption_options in cassandra.yaml* + +[source, plaintext] +---- +server_encryption_options: + internode_encryption: all + optional: true + keystore: conf/.keystore + keystore_password: cassandra + outbound_keystore: conf/.outbound_keystore + outbound_keystore_password: cassandra + require_client_auth: true // for enabling mTLS + truststore: conf/.truststore + truststore_password: cassandra +---- + +*STEP 2: Configure Internode Authenticator and Validator* + +Configure mTLS Internode authenticator and validator. If you are +implementing a custom validator, use that instead of Spiffe validator +[source, plaintext] +---- +internode_authenticator: + class_name : org.apache.cassandra.auth.MutualTlsInternodeAuthenticator + parameters : + validator_class_name: org.apache.cassandra.auth.SpiffeCertificateValidator + trusted_peer_identities : "spiffe1,spiffe2" +---- + +*STEP 3: Bounce the cluster* +Once the cluster is bounced all internode communications will be authenticated by mTLS +authenticator. + +== Migration from existing password based authentication +* For client connections, since the migration will not happen overnight, +the operators can run cassandra in optional mTLS mode and use +`MutualTlsWithPasswordFallbackAuthenticator` which will accept both mTLS & password +based connections, based on the type of connection client is making. These settings +can be configured in `cassandra.yaml`. Once all the clients migrate to using mTLS, +turn off optional mode and set the authenticator to be `MutualTlsAuthenticator`. From +that point only mTLS client connections will be accepted. + +* For Internode connections, while doing rolling upgrades from non-mTLS based configuration +to mTLS based configuration, use optional mode for the new nodes to be able to connect to Review Comment: use optional mode - it would be good to be more specific with how to set optional mode. An operator could think you mean set `optional: true` in encryption settings which could weaken settings during a migration, rather than set the authenticator to `MutualTlsWithPasswordFallbackAuthenticator` ########## src/java/org/apache/cassandra/auth/MutualTlsInternodeAuthenticator.java: ########## @@ -0,0 +1,226 @@ +/* + * Licensed to the Apache Software Foundation (ASF) under one + * or more contributor license agreements. See the NOTICE file + * distributed with this work for additional information + * regarding copyright ownership. The ASF licenses this file + * to you under the Apache License, Version 2.0 (the + * "License"); you may not use this file except in compliance + * with the License. You may obtain a copy of the License at + * + * http://www.apache.org/licenses/LICENSE-2.0 + * + * Unless required by applicable law or agreed to in writing, software + * distributed under the License is distributed on an "AS IS" BASIS, + * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. + * See the License for the specific language governing permissions and + * limitations under the License. + */ + +package org.apache.cassandra.auth; + +import java.io.InputStream; +import java.net.InetAddress; +import java.nio.file.Files; +import java.nio.file.Paths; // checkstyle: permit this import +import java.security.KeyStore; +import java.security.cert.Certificate; +import java.util.ArrayList; +import java.util.Arrays; +import java.util.Collections; +import java.util.Enumeration; +import java.util.List; +import java.util.Map; +import java.util.concurrent.TimeUnit; +import java.util.stream.Collectors; + +import com.google.common.annotations.VisibleForTesting; +import org.apache.commons.lang3.StringUtils; +import org.slf4j.Logger; +import org.slf4j.LoggerFactory; + +import org.apache.cassandra.config.Config; +import org.apache.cassandra.config.DatabaseDescriptor; +import org.apache.cassandra.config.EncryptionOptions; +import org.apache.cassandra.config.ParameterizedClass; +import org.apache.cassandra.exceptions.AuthenticationException; +import org.apache.cassandra.exceptions.ConfigurationException; +import org.apache.cassandra.utils.NoSpamLogger; + +/* + * Performs mTLS authentication for internode connections by extracting identities from the certificates of incoming + * connection and verifying them against a list of authorized peers. Authorized peers can be configured in + * trusted_peer_identities in cassandra yaml, otherwise authenticator trusts connections from peers which has the same + * identity as the one that the node uses for making outbound connections. + * + * Optionally one can validate the identity extracted from outbound keystore with node_identity that is configured in Review Comment: ```suggestion * Optionally Cassandra can validate the identity extracted from outbound keystore with node_identity that is configured in ``` ########## doc/modules/cassandra/pages/getting-started/mtlsauthenticators.adoc: ########## @@ -0,0 +1,133 @@ += Getting started with mTLS authenticators + +When a certificate based authentication protocol like TLS is used for client and +Internode connections, `MutualTlsAuthenticator` & `MutualTlsInternodeAuthenticator` +can be used for the authentication by leveraging the client certificates from the +SSL handshake. + +After SSL handshake, identity from the client certificates is extracted and only +authorized users will be granted access. + +== What is an Identity + +One can define their own identity for certificates by extracting some fields or +information from the certificates. one can implement the interface `MutualTlsCertificateValidator` +to provide logic for validating & extracting identity from the certificates. + +There is a default implementation of `MutualTlsCertificateValidator` with +https://spiffe.io/docs/latest/spiffe-about/spiffe-concepts/[SPIFFE] as the identity +of the certificates.This requires spiffe to be present in the SAN of the certificate. +One can implement their own validator that suits their needs. + +For example, instead of using `SPIFFE` based validator a `CN` based validator can be +implemented. + +== Configuring mTLS authenticator for client connections + +Note that the following steps uses SPIFFE identity as an example, If you are using +a custom validator, use appropriate identity in place of `spiffe://testdomain.com/testIdentifier/testValue`. + +*STEP 1: Add authorized users to system_auth.identity_to_roles table* + +Note that only users with permissions to create/modify roles can add/remove identities. +Client certificates with the identities in this table will be trusted by C*. +[source, plaintext] +---- +ADD IDENTITY 'spiffe://testdomain.com/testIdentifier/testValue' TO ROLE 'read_only_user' +---- + +*STEP 2: Configure Cassandra.yaml with right properties* + +`client_encryption_options` configuration for mTLS connections +[source, plaintext] +---- +client_encryption_options: + enabled: true + optional: false + keystore: conf/.keystore + keystore_password: cassandra + truststore: conf/.truststore + truststore_password: cassandra + require_client_auth: false // to enable mTLS +---- +Configure mTLS authenticator and the validator for client connections . If you are +implementing a custom validator, use that instead of Spiffe validator +[source, plaintext] +---- +authenticator: + class_name : org.apache.cassandra.auth.MutualTlsAuthenticator + parameters : + validator_class_name: org.apache.cassandra.auth.SpiffeCertificateValidator +---- + +*STEP 3: Bounce the cluster* + +After the bounce, C* will accept mTLS connections from the clients and if their +identity is present in the `identity_to_roles` table, access will be granted. + +== Configuring mTLS authenticator for Internode connections + +Internode authenticator trusts certificates whose identities are present in +`internode_authenticator.parameters.trusted_peer_identities` if configured. + +Otherwise, it trusts connections which have the same identity as the node. +When a node is making an outbound connection to another node, it uses the +certificate configured in `server_encryption_options.outbound_keystore`. +During the start of the node, identity is extracted from the outbound keystore and +connections from other nodes who have the same identity will be trusted if +`trusted_peer_identities` is not configured. + +For example, if a node has `testIdentity` embedded in the certificate in +outbound keystore, It trusts connections from other nodes when their certificates +have `testIdentity` embedded in them. + +There is an optional configuration `node_identity` that can be used to verify identity +extracted from the keystore to avoid any configuration errors. + +*STEP 1: Configure server_encryption_options in cassandra.yaml* + +[source, plaintext] +---- +server_encryption_options: + internode_encryption: all + optional: true + keystore: conf/.keystore + keystore_password: cassandra + outbound_keystore: conf/.outbound_keystore + outbound_keystore_password: cassandra + require_client_auth: true // for enabling mTLS + truststore: conf/.truststore + truststore_password: cassandra +---- + +*STEP 2: Configure Internode Authenticator and Validator* + +Configure mTLS Internode authenticator and validator. If you are +implementing a custom validator, use that instead of Spiffe validator +[source, plaintext] +---- +internode_authenticator: + class_name : org.apache.cassandra.auth.MutualTlsInternodeAuthenticator + parameters : + validator_class_name: org.apache.cassandra.auth.SpiffeCertificateValidator + trusted_peer_identities : "spiffe1,spiffe2" +---- + +*STEP 3: Bounce the cluster* +Once the cluster is bounced all internode communications will be authenticated by mTLS Review Comment: ```suggestion Once all nodes in the cluster are restated, all internode communications will be authenticated by mTLS ``` might be nice to say it a different way - bounce is a bit of an idiom so may be helpful to spell it out. ########## doc/modules/cassandra/pages/getting-started/mtlsauthenticators.adoc: ########## @@ -0,0 +1,133 @@ += Getting started with mTLS authenticators + +When a certificate based authentication protocol like TLS is used for client and +Internode connections, `MutualTlsAuthenticator` & `MutualTlsInternodeAuthenticator` +can be used for the authentication by leveraging the client certificates from the +SSL handshake. + +After SSL handshake, identity from the client certificates is extracted and only +authorized users will be granted access. + +== What is an Identity + +One can define their own identity for certificates by extracting some fields or +information from the certificates. one can implement the interface `MutualTlsCertificateValidator` +to provide logic for validating & extracting identity from the certificates. + +There is a default implementation of `MutualTlsCertificateValidator` with +https://spiffe.io/docs/latest/spiffe-about/spiffe-concepts/[SPIFFE] as the identity +of the certificates.This requires spiffe to be present in the SAN of the certificate. +One can implement their own validator that suits their needs. + +For example, instead of using `SPIFFE` based validator a `CN` based validator can be +implemented. + +== Configuring mTLS authenticator for client connections + +Note that the following steps uses SPIFFE identity as an example, If you are using +a custom validator, use appropriate identity in place of `spiffe://testdomain.com/testIdentifier/testValue`. + +*STEP 1: Add authorized users to system_auth.identity_to_roles table* + +Note that only users with permissions to create/modify roles can add/remove identities. +Client certificates with the identities in this table will be trusted by C*. +[source, plaintext] +---- +ADD IDENTITY 'spiffe://testdomain.com/testIdentifier/testValue' TO ROLE 'read_only_user' +---- + +*STEP 2: Configure Cassandra.yaml with right properties* + +`client_encryption_options` configuration for mTLS connections +[source, plaintext] +---- +client_encryption_options: + enabled: true + optional: false + keystore: conf/.keystore + keystore_password: cassandra + truststore: conf/.truststore + truststore_password: cassandra + require_client_auth: false // to enable mTLS Review Comment: ```suggestion require_client_auth: false // while migrating to mTLS, keep permitting non-validated certs ``` ########## doc/modules/cassandra/pages/getting-started/mtlsauthenticators.adoc: ########## @@ -0,0 +1,133 @@ += Getting started with mTLS authenticators + +When a certificate based authentication protocol like TLS is used for client and +Internode connections, `MutualTlsAuthenticator` & `MutualTlsInternodeAuthenticator` +can be used for the authentication by leveraging the client certificates from the +SSL handshake. + +After SSL handshake, identity from the client certificates is extracted and only +authorized users will be granted access. + +== What is an Identity + +One can define their own identity for certificates by extracting some fields or +information from the certificates. one can implement the interface `MutualTlsCertificateValidator` +to provide logic for validating & extracting identity from the certificates. + +There is a default implementation of `MutualTlsCertificateValidator` with +https://spiffe.io/docs/latest/spiffe-about/spiffe-concepts/[SPIFFE] as the identity +of the certificates.This requires spiffe to be present in the SAN of the certificate. +One can implement their own validator that suits their needs. + +For example, instead of using `SPIFFE` based validator a `CN` based validator can be +implemented. Review Comment: ```suggestion Instead of using `SPIFFE` based validator a `CN` based validator could by an operator-supplied custom class that implements `MutualTlsCertificateValidator`. ``` ########## doc/modules/cassandra/pages/getting-started/mtlsauthenticators.adoc: ########## @@ -0,0 +1,133 @@ += Getting started with mTLS authenticators + +When a certificate based authentication protocol like TLS is used for client and +Internode connections, `MutualTlsAuthenticator` & `MutualTlsInternodeAuthenticator` +can be used for the authentication by leveraging the client certificates from the +SSL handshake. + +After SSL handshake, identity from the client certificates is extracted and only +authorized users will be granted access. + +== What is an Identity + +One can define their own identity for certificates by extracting some fields or +information from the certificates. one can implement the interface `MutualTlsCertificateValidator` +to provide logic for validating & extracting identity from the certificates. + +There is a default implementation of `MutualTlsCertificateValidator` with +https://spiffe.io/docs/latest/spiffe-about/spiffe-concepts/[SPIFFE] as the identity +of the certificates.This requires spiffe to be present in the SAN of the certificate. +One can implement their own validator that suits their needs. + +For example, instead of using `SPIFFE` based validator a `CN` based validator can be +implemented. + +== Configuring mTLS authenticator for client connections + +Note that the following steps uses SPIFFE identity as an example, If you are using +a custom validator, use appropriate identity in place of `spiffe://testdomain.com/testIdentifier/testValue`. + +*STEP 1: Add authorized users to system_auth.identity_to_roles table* + +Note that only users with permissions to create/modify roles can add/remove identities. +Client certificates with the identities in this table will be trusted by C*. +[source, plaintext] +---- +ADD IDENTITY 'spiffe://testdomain.com/testIdentifier/testValue' TO ROLE 'read_only_user' +---- + +*STEP 2: Configure Cassandra.yaml with right properties* + +`client_encryption_options` configuration for mTLS connections +[source, plaintext] +---- +client_encryption_options: + enabled: true + optional: false + keystore: conf/.keystore + keystore_password: cassandra + truststore: conf/.truststore + truststore_password: cassandra + require_client_auth: false // to enable mTLS +---- +Configure mTLS authenticator and the validator for client connections . If you are +implementing a custom validator, use that instead of Spiffe validator +[source, plaintext] +---- +authenticator: + class_name : org.apache.cassandra.auth.MutualTlsAuthenticator + parameters : + validator_class_name: org.apache.cassandra.auth.SpiffeCertificateValidator +---- + +*STEP 3: Bounce the cluster* + +After the bounce, C* will accept mTLS connections from the clients and if their +identity is present in the `identity_to_roles` table, access will be granted. + +== Configuring mTLS authenticator for Internode connections + +Internode authenticator trusts certificates whose identities are present in +`internode_authenticator.parameters.trusted_peer_identities` if configured. + +Otherwise, it trusts connections which have the same identity as the node. +When a node is making an outbound connection to another node, it uses the +certificate configured in `server_encryption_options.outbound_keystore`. +During the start of the node, identity is extracted from the outbound keystore and +connections from other nodes who have the same identity will be trusted if +`trusted_peer_identities` is not configured. + +For example, if a node has `testIdentity` embedded in the certificate in +outbound keystore, It trusts connections from other nodes when their certificates +have `testIdentity` embedded in them. + +There is an optional configuration `node_identity` that can be used to verify identity +extracted from the keystore to avoid any configuration errors. + +*STEP 1: Configure server_encryption_options in cassandra.yaml* + +[source, plaintext] +---- +server_encryption_options: + internode_encryption: all + optional: true + keystore: conf/.keystore + keystore_password: cassandra + outbound_keystore: conf/.outbound_keystore + outbound_keystore_password: cassandra + require_client_auth: true // for enabling mTLS Review Comment: I think we force this true for internode connections, so not sure if this setting really matters ########## src/java/org/apache/cassandra/auth/MutualTlsInternodeAuthenticator.java: ########## @@ -0,0 +1,226 @@ +/* + * Licensed to the Apache Software Foundation (ASF) under one + * or more contributor license agreements. See the NOTICE file + * distributed with this work for additional information + * regarding copyright ownership. The ASF licenses this file + * to you under the Apache License, Version 2.0 (the + * "License"); you may not use this file except in compliance + * with the License. You may obtain a copy of the License at + * + * http://www.apache.org/licenses/LICENSE-2.0 + * + * Unless required by applicable law or agreed to in writing, software + * distributed under the License is distributed on an "AS IS" BASIS, + * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. + * See the License for the specific language governing permissions and + * limitations under the License. + */ + +package org.apache.cassandra.auth; + +import java.io.InputStream; +import java.net.InetAddress; +import java.nio.file.Files; +import java.nio.file.Paths; // checkstyle: permit this import +import java.security.KeyStore; +import java.security.cert.Certificate; +import java.util.ArrayList; +import java.util.Arrays; +import java.util.Collections; +import java.util.Enumeration; +import java.util.List; +import java.util.Map; +import java.util.concurrent.TimeUnit; +import java.util.stream.Collectors; + +import com.google.common.annotations.VisibleForTesting; +import org.apache.commons.lang3.StringUtils; +import org.slf4j.Logger; +import org.slf4j.LoggerFactory; + +import org.apache.cassandra.config.Config; +import org.apache.cassandra.config.DatabaseDescriptor; +import org.apache.cassandra.config.EncryptionOptions; +import org.apache.cassandra.config.ParameterizedClass; +import org.apache.cassandra.exceptions.AuthenticationException; +import org.apache.cassandra.exceptions.ConfigurationException; +import org.apache.cassandra.utils.NoSpamLogger; + +/* + * Performs mTLS authentication for internode connections by extracting identities from the certificates of incoming + * connection and verifying them against a list of authorized peers. Authorized peers can be configured in + * trusted_peer_identities in cassandra yaml, otherwise authenticator trusts connections from peers which has the same + * identity as the one that the node uses for making outbound connections. + * + * Optionally one can validate the identity extracted from outbound keystore with node_identity that is configured in + * cassandra.yaml to avoid any configuration errors. + * + * Authenticator & Certificate validator can be configured using cassandra.yaml, one can write their own mTLS certificate Review Comment: ```suggestion * Authenticator & Certificate validator can be configured using cassandra.yaml, operators can write their own mTLS certificate ``` ########## doc/modules/cassandra/pages/developing/cql/cql_singlefile.adoc: ########## @@ -2235,6 +2235,57 @@ LIST ROLES; but only roles with the `LOGIN` privilege are included in the output. +[[databaseIdentity]] +=== Database Identities + +[[AddIdentityStmt]] +==== ADD IDENTITY + +_Syntax:_ + +bc(syntax).. + +::= ADD IDENTITY ( IF NOT EXISTS )? TO ROLE ? + +_Sample:_ + +bc(sample). + +ADD IDENTITY 'id1' TO ROLE 'role1'; + +Only a user with previleges to add roles can add identities Review Comment: ```suggestion Only a user with privileges to add roles can add identities ``` ########## src/java/org/apache/cassandra/auth/MutualTlsInternodeAuthenticator.java: ########## @@ -0,0 +1,226 @@ +/* + * Licensed to the Apache Software Foundation (ASF) under one + * or more contributor license agreements. See the NOTICE file + * distributed with this work for additional information + * regarding copyright ownership. The ASF licenses this file + * to you under the Apache License, Version 2.0 (the + * "License"); you may not use this file except in compliance + * with the License. You may obtain a copy of the License at + * + * http://www.apache.org/licenses/LICENSE-2.0 + * + * Unless required by applicable law or agreed to in writing, software + * distributed under the License is distributed on an "AS IS" BASIS, + * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. + * See the License for the specific language governing permissions and + * limitations under the License. + */ + +package org.apache.cassandra.auth; + +import java.io.InputStream; +import java.net.InetAddress; +import java.nio.file.Files; +import java.nio.file.Paths; // checkstyle: permit this import +import java.security.KeyStore; +import java.security.cert.Certificate; +import java.util.ArrayList; +import java.util.Arrays; +import java.util.Collections; +import java.util.Enumeration; +import java.util.List; +import java.util.Map; +import java.util.concurrent.TimeUnit; +import java.util.stream.Collectors; + +import com.google.common.annotations.VisibleForTesting; +import org.apache.commons.lang3.StringUtils; +import org.slf4j.Logger; +import org.slf4j.LoggerFactory; + +import org.apache.cassandra.config.Config; +import org.apache.cassandra.config.DatabaseDescriptor; +import org.apache.cassandra.config.EncryptionOptions; +import org.apache.cassandra.config.ParameterizedClass; +import org.apache.cassandra.exceptions.AuthenticationException; +import org.apache.cassandra.exceptions.ConfigurationException; +import org.apache.cassandra.utils.NoSpamLogger; + +/* + * Performs mTLS authentication for internode connections by extracting identities from the certificates of incoming + * connection and verifying them against a list of authorized peers. Authorized peers can be configured in + * trusted_peer_identities in cassandra yaml, otherwise authenticator trusts connections from peers which has the same + * identity as the one that the node uses for making outbound connections. + * + * Optionally one can validate the identity extracted from outbound keystore with node_identity that is configured in + * cassandra.yaml to avoid any configuration errors. + * + * Authenticator & Certificate validator can be configured using cassandra.yaml, one can write their own mTLS certificate + * validator and configure it in cassandra.yaml.Below is an example on how to configure validator. + * Note that this example uses SPIFFE based validator,It could be any other validator with any defined identifier format. Review Comment: ```suggestion * Note that this example uses SPIFFE based validator, it could be any other validator with any defined identifier format. ``` -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
