-
The DC/OS Apache Cassandra service allows you to create a service account to configure access for Apache Cassandra. The service allows you to create and assign permissions as required for access.
-
The DC/OS Apache Cassandra service supports Apache Cassandra’s native transport encryption mechanisms. The service provides automation and orchestration to simplify the usage of the following features.
NOTE: These security features are only available on DC/OS Enterprise 1.10 and later.
This section describes how to configure DC/OS access for Apache Cassandra. Depending on your security mode, Apache Cassandra may require service authentication for access to DC/OS.
A service like Apache Cassandra typically performs certain privileged actions on the cluster, which might require authenticating with the cluster. A service account associated with the service is used to authenticate with the DC/OS cluster. It is recommended to provisioning a separate service account for each service that would perform privileged operations. Service accounts authenticate using public-private keypair. The public key is used to create the service account in the cluster, while the corresponding private key is stored in the secret store. The service account and the service account secret are passed to the service as install time options.
| Security mode | Service Account |
|---|---|
| Disabled | Not available |
| Permissive | Optional |
| Strict | Required |
If you install a service in permissive mode and do not specify a service account, Metronome and Marathon will act as if requests made by this service are made by an account with the superuser permission.
Prerequisites:
- DC/OS CLI installed and be logged in as a superuser.
- Enterprise DC/OS CLI 0.4.14 or later installed.
In this step, a 2048-bit RSA public-private key pair is created using the Enterprise DC/OS CLI.
Create a public-private key pair and save each value into a separate file within the current directory.
dcos security org service-accounts keypair <private-key>.pem <public-key>.pem
NOTE: You can use the DC/OS Secret Store to secure the key pair.
From a terminal prompt, create a new service account (for example, cassandra) containing the public key (<your-public-key>.pem).
dcos security org service-accounts create -p <your-public-key>.pem -d <description> cassandra
You can verify your new service account using the following command.
dcos security org service-accounts show cassandra
Create a secret (cassandra/<secret-name>) with your service account and private key specified (<private-key>.pem).
NOTE: If you store your secret in a path that matches the service name, for example, service name and secret path are both cassandra, then only the service named cassandra can access it.
dcos security secrets create-sa-secret <private-key>.pem <service-account-id> cassandra/<secret-name>
NOTE: If you are running, now EOL-ed, DC/OS 1.11 or older you would need to add --strict to the above command. For example, dcos security secrets --strict create-sa-secret .pem cassandra/sa-secret .
You can list the secrets with this command:
dcos security secrets list /
Use the following DC/OS CLI commands to rapidly provision the Apache Cassandra service account with the required permissions.
- Create the permission.
IMPORTANT: The value to be used for <service-role> will be based on the service name, package version and DC/OS version. The table below shows a few examples of service names and the corresponding Mesos roles they would use. This version of cassandra is quota support built in. To determine whether the service group, you are deploying a service to, has enforceRole set to true or false please check this KB article.
If you need help configuring the permissions for cassandra, please feel to reach out to D2iQ support by filing a support ticket. Replace the instances of <service-role> with the correct name (<name>-role).
| Service name | <service-role> DC/OS 1.13 or older DC/OS 2.0 or newer AND enforceRole=false |
<service-role> DC/OS 2.0 or newer AND enforceRole=true |
|---|---|---|
/cassandra |
cassandra-role |
cassandra-role |
/cassandra-prod |
cassandra-prod-role |
cassandra-prod-role |
/team01/cassandra |
team01__cassandra-role |
team01 |
/team01/prod/cassandra |
team01__prod__cassandra-role |
team01 |
Permissive
Run these commands with the service account name you created for the service in the Create a Service Account step above. For example we are using cassandra
dcos security org users grant cassandra dcos:mesos:master:framework:role:<service-role> create --description "Allow registering as a framework of role <service-role> with Mesos master" dcos security org users grant cassandra dcos:mesos:master:reservation:role:<service-role> create --description "Allow creating Mesos resource reservations of role <service-role>" dcos security org users grant cassandra dcos:mesos:master:volume:role:<service-role> create --description "Allow creating Mesos persistent volumes of role <service-role>" dcos security org users grant cassandra dcos:mesos:master:reservation:principal:cassandra delete --description "Allow unreserving Mesos resource reservations with principal cassandra" dcos security org users grant cassandra dcos:mesos:master:volume:principal:cassandra delete --description "Allow deleting Mesos persistent volumes with principal cassandra"
Strict
Run these commands with the service account name you created for the service in the Create a Service Account step above. For example we are using cassandra
dcos security org users grant cassandra dcos:mesos:master:task:user:nobody create --description "Allow running a task as linux user nobody" dcos security org users grant cassandra dcos:mesos:master:framework:role:<service-role> create --description "Allow registering as a framework of role <service-role> with Mesos master" dcos security org users grant cassandra dcos:mesos:master:reservation:role:<service-role> create --description "Allow creating Mesos resource reservations of role <service-role>" dcos security org users grant cassandra dcos:mesos:master:volume:role:<service-role> create --description "Allow creating Mesos persistent volumes of role <service-role>" dcos security org users grant cassandra dcos:mesos:master:reservation:principal:cassandra delete --description "Allow unreserving Mesos resource reservations with principal cassandra" dcos security org users grant cassandra dcos:mesos:master:volume:principal:cassandra delete --description "Allow deleting Mesos persistent volumes with principal cassandra"
With transport encryption enabled, DC/OS Apache Cassandra 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 Apache Cassandra 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>
}
}
}
}
NOTE: It is possible to update a running DC/OS Apache Cassandra service to enable transport encryption after initial installation, but the service may be unavailable during the transition. Additionally, your clients will need to be reconfigured unless service.security.transport_encryption.allow_plaintext is set to true.
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.
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 Apache Cassandra 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 node-0-server.<service-name>.cluster-1.acmeco.net.
