Every company’s most valuable asset is its data. However, that data is also constantly under threat from bad actors around the world. To retain the trust of their customers, partners, and shareholders, every business needs to protect their data and applications. DC/OS Enterprise offers a range of features that allows you to secure your cluster and prevent breaches and other attacks. So, let’s see the various different mechanisms through which DC/OS manages the security.

DC/OS is based on a Linux kernel and userspace. The same best practices for securing any Linux system apply to securing DC/OS, including setting correct file permissions, restricting root and normal user accounts, protecting network interfaces with iptables or other firewalls, and regularly applying updates from the Linux distribution used with DC/OS to ensure that system libraries, utilities, and core services like systemd and OpenSSH are secure.

The goals of DC/OS security are:

• Isolate the cluster perimeter with strong authentication and authorization across all interfaces.
• Secure and protect the internal cluster communication, containers, and sandboxes.
• Enhance cluster security with support for 3rd party security integrations.

Security Zones

At the highest level, we can distinguish three security zones in a DC/OS deployment, which are admin, private, and public security zones.

• The admin zone is accessible via HTTP/HTTPS and SSH connections and provides access to the master nodes. It also provides reverse proxy access to the other nodes in the cluster via URL routing. Access to the admin zone is controlled by the Admin Router. The Admin Router denies access to most HTTP endpoints for unauthenticated requests. In order for a request to be authenticated, it needs to present a valid authentication token in its Authorization header.
• The private zone is a non-routable network that is only accessible from the admin zone or through the edge router from the public zone. Deployed services are run in the private zone. This zone is where the majority of agent nodes are run.
• The optional public zone is where publicly accessible applications are run. Generally, only a small number of agent nodes run in this zone. The edge router forwards traffic to applications running in the private zone. These agent nodes have both public and private IP addresses and only specific ports should be open in their iptables firewall.

Security Modes

We can control DC/OS Enterprise access by resource and operation. The available security modes are disabled, permissive, and strict. The strict mode provides the finest-grained controls. The DC/OS permissions are enforced based on your security mode. The security mode is set during DC/OS installation and can only be changed by performing an upgrade.

Disabled:- This mode is designed to ensure smooth upgrades from earlier versions of DC/OS, but only provides minimal security features and is not intended for production environments. The disabled mode does not provide Marathon or Mesos permissions.

Permissive:- This mode provides some of the security features, but does not include the Mesos permissions.

Strict:- This mode provides the most robust security posture and requires a significant amount of configuration.

Authentication

All requests from outside of the DC/OS cluster require an authentication token. The DC/OS authentication token is a JSON web token (JWT) that expires five days after issuance by default. The default expiration can be modified during installation or upgrade. When the authentication token expires, the user can re-authenticate to receive another. DC/OS provisions masters with ZooKeeper credentials during the bootstrap sequence.

User Login

Users can log in by using the DC/OS GUI, the DC/OS CLI, or a programmatic client.

• Lightweight Directory Access Protocol (LDAP) is an open, vendor-neutral, industry standard application protocol for accessing and maintaining distributed directory information services over an Internet Protocol (IP) network. If you have configured an LDAP directory server, DC/OS will pass the user’s credentials to the LDAP directory server for verification.
• Security Assertion Markup Language (SAML) is an open standard for exchanging authentication and authorization data between parties, in particular, between an identity provider and a service provider. OpenID Connect is a simple identity layer on top of the OAuth 2.0 protocol, which allows computing clients to verify the identity of an end-user based on the authentication performed by an authorization server, as well as to obtain basic profile information about the end-user in an interoperable and REST-like manner. If you have configured a SAML or an OpenID Connect identity provider (IdP), the user passes their credentials directly to the IdP.

When a user logs in with the DC/OS GUI, the Identity and Access Manager plants a cookie that contains the authentication token. Clearing the cookie does not invalidate the authentication token. If sniffed over an unencrypted connection or extracted from the cookie, someone could use the authentication token to log into DC/OS. Users should Sign Out at the end of their browser session to clear this cookie.

Passwords

Credentials for cluster-local user accounts (those not using LDAP, SAML, or OpenID Connect) consist of a username and password that can be used to validate user passwords. Passwords are individually salted and cryptographically hashed using crypt(3) SHA-512. Once DC/OS Identity and Access Management (IAM) has validated user credentials, an authentication token is returned to the user. The authentication token is then used for further request authentication during the user session. This way the password does not need to be stored in the client and is only sent over the wire immediately after the user enters it.

Authorization

In addition to authenticating requests, DC/OS also checks the permissions associated with the account to determine whether the requestor is authorized to access the requested resource. The sequence in the diagram illustrates how permission enforcement varies by security mode.

• The Admin Router and the Secret Store enforce their permissions in all security modes.
• Metronome and Marathon enforce their permissions in permissive and strict modes. However, the enforcement in permissive mode only occurs if the requestor presents an authentication token, which is optional in permissive mode. If an in-cluster requestor does not present an authentication token, Metronome and Marathon will act as if the request was made by a user with the dcos:superuser permission.
• The Mesos masters and agents enforce their permissions only in strict security mode.

Spaces

Spaces allow you to:

• Restrict user access to services and jobs.You can put services and jobs into groups in any security mode. This can help users find the jobs or services that pertain to them. In strict and permissive security modes, you can use permissions to restrict user’s access on a per service/job or service/job group basis.
• Restrict service access to secrets. The secret path controls which services can access it. If you do not specify a path when storing a secret, any service can access it. Secret paths work in conjunction with service groups to control access. However, you do not need to have service groups to control access to secrets, you can also use the name of the service.

Secure Storage and Transport of Secrets

DC/OS stores Secret Store data in ZooKeeper encrypted under an unseal key using the Advanced Encryption Standard (AES) algorithm in Galois Counter Mode (GCM). The Secret Store uses the unseal key to encrypt secrets before sending them to ZooKeeper and to decrypt secrets after receiving them from ZooKeeper. This ensures that secrets are encrypted both at rest and in transit. TLS provides an additional layer of encryption on the secrets in transit from ZooKeeper to the Secret Store.The unseal key is encrypted under a public GPG key. Requests to the Secrets API return only the encrypted unseal key. When the Secret Store becomes sealed, either manually or due to a failure, the private GPG key must be used to decrypt the unseal key and unseal the Secret Store.By default, you cannot store a secret larger than one megabyte.

Fine-grained Access Control of Secrets

DC/OS allows you to restrict:

• User access to secrets: use permissions to control which users can access what secrets and what operations they can perform.
• Application access to secrets: use spaces to control which applications can retrieve what secrets.

So, above mentioned are some of the security features DC/OS has implemented which has made it secure but more complicated to use for a layman. But in today’s Internet, where the data has become an asset which can be traded on the black market, it’s worth some inconvenience to keep your data safe.