Security is at the very core of what we do at CommandK. At CommandK, every product feature, every service rollout - has security as an absolute acceptance criterion.

Encryption in Transit

All CommandK services run behind load balancers that run with HSTS configured, and a minimum TLS version of v1.2. All certificate management is automated and managed via AWS ACM and is issued for up to 1 year.
All services run in a hardened EKS cluster, and we use mTLS for complete end-to-end encryption, ensuring that all inter-service traffic is also encrypted. Furthermore, all communication to our databases, and vault storage is also performed over encrypted channels.

Secret Storage

All secrets are stored in dedicated, isolated, secret vaults. CommandK vaults are developed on confidant, a battle-tested secret storage solution. When you sign up, we create dedicated vaults, each vault having its own dedicated KMS key for encryption. The vaults can then be configured for your different environments to store their data in, and these vaults are entirely isolated to your account - they are not shared with any other customer.
All secrets are encrypted using AWS KMS (using AES-GCM-256) and DynamoDB is used to store the encrypted secrets. CommandK only uses AWS-managed keys, and as such has no access to the private key material.

No secret is ever stored in our database - which is only used for storing customer metadata. Each vault:

1. Runs as its own K8S deployment, with a dedicated K8S ServiceAccount for compute isolation
2. Has its own dedicated KMS key for encryption
3. Has its own DynamoDB table for storing the encrypted values
4. Has a dedicated IAM role with a very narrow permission that only allows operation on the dedicated KMS key and the DynamoDB table

In addition to this, all CommandK vaults run in a dedicated group of EC2 instances - where they do not share compute with any other services. All network traffic to our vaults is restricted via istio policies.

Access Control

Each storage vault has exactly a single IAM role that can be used to perform operations on it. The trust policy of each of these IAM roles completely restricts the service accounts that can assume this role. Further, we have used AWS CloudTrail and AWS CloudWatch in conjunction to trigger P0 alerts in the case of:

1. Any access to any of the DynamoDB tables (which only store encrypted data) by any IAM entity other than the dedicated role
2. Any form of KMS operation on the vault key by any IAM entity other than the dedicated role
3. Any assumption of the dedicated role performed by an unrecognized IAM entity

Our EKS clusters are hardened, keeping the following measures in mind:

1. Execution on pods is completely disabled cluster-wide
2. Cluster access is completely restricted for all developers
3. CloudTrail and CloudWatch are used to push a P0 alert in case of any IAM role assumption from an unrecognized role

Metadata Storage

We use a shared database for storing all customer metadata in a managed PostgreSQL database. All customer data follows strict logical isolation - our query model to the database is extra-eager, which requires an additional degree of logical isolation check, involving an additional layer of redundancy. We maintain comprehensive automated testing to ensure that all exposed functionality maintains logical isolation.

Software Security

To ensure that our software and products are free from vulnerabilities, and security bugs, we take multiple steps to constantly monitor our security posture:

1. Integration with tools like snyk, pingsafe to be notified of vulnerabilities, and acting on them with utmost urgency
2. Annual VAPT by an external agency
3. Security architecture, model, and infrastructure review and audit by a reputed security consultancy company