DC/OS DataStax Enterprise Security
The DC/OS DataStax Enterprise service supports DSE’s native transport encryption mechanisms. The service provides automation and orchestration to simplify the usage of these important features.
Transport Encryption
With transport encryption enabled, DC/OS DataStax Enterprise will automatically deploy all nodes with the correct configuration to encrypt communication via SSL. The nodes will communicate securely between themselves using SSL.
The service uses the DC/OS CA to generate the SSL artifacts that it uses to secure the service. Any client that trusts the DC/OS CA will consider the service’s certificates valid.
Prerequisites
- A DC/OS Service Account with a secret stored in the DC/OS Secret Store.
- DC/OS Superuser permissions for modifying the permissions of the Service Account.
Configure Transport Encryption
Set up the service account
Grant the service account the correct permissions.
- In DC/OS 1.10, the required permission is
dcos:superuser full
. - In DC/OS 1.11 and later, the required permissions are:
dcos:secrets:default:/<service name>/* full
dcos:secrets:list:default:/<service name> read
dcos:adminrouter:ops:ca:rw full
dcos:adminrouter:ops:ca:ro full
where <service name>
is the name of the service to be installed.
Run the following DC/OS Enterprise CLI commands to set permissions for the service account on a strict cluster:
dcos security org users grant ${SERVICE_ACCOUNT} dcos:mesos:master:task:app_id:<service/name> create
dcos security org users grant ${SERVICE_ACCOUNT} dcos:mesos:master:reservation:principal:dev_hdfs create
dcos security org users grant ${SERVICE_ACCOUNT} dcos:mesos:master:volume:principal:dev_hdfs create
Install the service
Install the DC/OS DataStax Enterprise service including the following options in addition to your own:
{
"service": {
"service_account": "<your service account name>",
"service_account_secret": "<full path of service secret>",
"security": {
"transport_encryption": {
"enabled": true, "allow_plaintext": <true|false default false>
}
}
}
}
Transport Encryption for Clients
With Transport Encryption enabled, service clients will need to be configured to use the DC/OS CA bundle to verify the connections they make to the service. Consult your client’s documentation for trusting a CA and configure your client appropriately.
DSE Authentication/Authorization Schemes
in DC/OS supports both internal and LDAP authentication/authorization schemes. You can configure both schemes and then select the order in which they are used, or you can configure just one, in which case only that scheme will be used. will try to authenticate with the default scheme first and fall back to the alternate scheme if it has been configured. More information about how handles this can be found in DataStax’s documentation
Enabling Authentication/Authorization
To enable authentication/authorization, follow these steps:
-
In the Advanced Installation wizard, configure the following fields:
In “cassandra” tab,
- Set
authenticator
tocom.datastax.bdp.cassandra.auth.DseAuthenticator
- Set
authorizer
tocom.datastax.bdp.cassandra.auth.DseAuthorizer
- Set
role_manager
tocom.datastax.bdp.cassandra.auth.DseRoleManager
In “dse” tab,
- Check AUTHENTICATION_OPTIONS_ENABLED checkbox
- Set AUTHENTICATION_OPTIONS_DEFAULT_SCHEME to either internal or ldap, depending on which scheme you want as the default
- Set AUTHENTICATION_OPTIONS_OTHER_SCHEMES to either internal or ldap (optional to configure the fallback)
- Set ROLE_MANAGEMENT_OPTIONS_MODE to either internal or ldap, according to your needs
- Check AUTHORIZATION_OPTIONS_ENABLED checkbox (optional to enable authorization)
- Set
-
If you are using only internal authorization, no further configuration is required for . If you are also using LDAP, then follow the directions below to configure LDAP authentication based on your needs.
LDAP Configuration
When you enable LDAP authentication in DataStax Enterprise, users and groups that are managed by external LDAP servers can be authenticated by DataStax Enterprise. To enable LDAP authentication with your cluster, you need to configure the followings:
-
In the Advanced Installation wizard, you need to configure the following fields according to your LDAP settings:
In “dse” tab,
- Check LDAP’s enabled checkbox
- Set
server_host
to your LDAP server FQDN or IP address - Set
server_port
of your LDAP server port (default is 389) - Set
search_dn
ex. cn=admin,dc=example,dc=org - Set
search_password
ex. secret - Set
user_search_base
ex. ou=People,dc=example,dc=org - Set
user_search_filter
ex. (uid={0}) - Set
user_memberof_attribut
e ex. memberof - Set
group_search_type
ex. memberof_search - Set
group_search_base
ex. ou=Groups,dc=example,dc=org - Set
group_search_filter
ex. (uniquemember={0}) - Set
group_name_attribute
(default is 0) - Set
credentials_validity_in_ms
(default is 0) - Set
search_validity_in_seconds
(default is 0) - Set
connection_pool_max_active
(default is 8) - Set
connection_pool_max_idle
(default is 8)
-
You will need to run the following CQL statements to grant relevant permission to your LDAP roles:
cqlsh> CREATE ROLE <role-name> WITH LOGIN = TRUE; (role-name is the corresponding role inside your LDAP) cqlsh> GRANT EXECUTE ON ALL AUTHENTICATION SCHEMES TO <role-name>; OR cqlsh> GRANT EXECUTE ON (INTERNAL|LDAP) SCHEME TO <role-name>;
Please refer to DataStax’s documentation for more detailed description of each field above.
OpsCenter LDAP Configuration
Configure LDAP (Lightweight Directory Access Protocol) for users accessing OpsCenter.
In the Advanced Installation wizard, configure the following fields according to your LDAP settings:
In “opscenter” tab,
- Check Authentication Configuration’s checkbox
- Set
login_user
to a LDAP user’s uid belonging to one or more LDAP groups in “admin_group_name” field below - Set
login_password
(the password associated with the login_user field above) - Set
method
to LDAP - Check LDAP Configuration’s checkbox
- Set
server_host
to your LDAP server FQDN or IP address - Set
server_port
of your LDAP server port (default is 389) - Set
search_dn
ex. cn=admin,dc=example,dc=org - Set
search_password
ex. secret - Set
user_search_base
ex. ou=People,dc=example,dc=org - Set
user_search_filter
ex. (uid={0}) - Set
user_memberof_attribute
ex. memberof - Set
group_search_type
ex. directory_search - Set
group_search_base
ex. ou=Groups,dc=example,dc=org - Set
group_search_filter_with_dn
ex. (member={0}) - Set
group_name_attribut
e ex. cn - Set
admin_group_name
ex. mygroup, manager, developer
Please refer to DataStax’s documentation for more detailed description of each field above. Once your Package service instance is ready, you can use your LDAP account to log in to OpsCenter to manage your cluster.
OpsCenter Internal Authentication Configuration
In the Advanced Installation wizard, configure the following fields:
In "opscenter" tab,
Check Authentication Configuration's checkbox
Leave login_user as admin (when you install the package the first time)
Leave login_password as admin (when you install the package the first time)
Once your Package service instance is ready, you can use “admin” and “admin” as the username and the password to log in to OpsCenter to start managing your cluster.
Forwarding DNS and Custom Domain
Every DC/OS cluster has a unique cryptographic ID which can be used to forward DNS queries to that cluster. To securely expose the service outside the cluster, external clients must have an upstream resolver configured to forward DNS queries to the DC/OS cluster of the service as described here.
With only forwarding configured, DNS entries within the DC/OS cluster will be resolvable at <task-domain>.autoip.dcos.<cryptographic-id>.dcos.directory
. However, if you configure a DNS alias, you can use a custom domain. For example, <task-domain>.cluster-1.acmeco.net
. In either case, the DC/OS DataStax Enterprise service will need to be installed with an additional security option:
{
"service": {
"security": {
"custom_domain": "<custom-domain>"
}
}
}
where <custom-domain>
is one of autoip.dcos.<cryptographic-id>.dcos.directory
or your organization’s specific domain (e.g., cluster-1.acmeco.net
).
As a concrete example, using the custom domain of cluster-1.acmeco.net
the node 0 task would have a host of dse-0-node.<service-name>.cluster-1.acmeco.net
.