soluto / kamus Goto Github PK

Currently, the DAST are not running due to Soluto/owasp-zap-glue-ci-images#4. When this bug is fixed we can re-enable the DAST.

Today, the encryptor and decryptor are using the same credentials for authentication with the KMS. This is not ideal, we should follow the least privileged role here - grant them the minimum required permission. This is more of an issue with how we deploy Kamus (Helm chart), but opening the issue here for now.

Similar to how Helm's working. Improve security + usability - no need to specify what is the URL of Kamus URL

The full spec is here

Currently, there is no code coverage report. This means that it is not clear to users how quality Kamus is, and whether or not they can trust it. Need to work on making a report available. Might be a challenge as we do mostly blackbox testing.

Hamuste decryptor (version 8) prints the decrypted values to the logs.

To support kubernetes cluster running on AWS. Look like there is support for it in the dotnet SDK.
Open questions:

• Is KMS the right choice here? Maybe HSM is a better choice?
• How do we handle authentication to KMS/HSM? Pod IAM?

See the labels here

• Threat Modeling
• Blog post
• How to use
• How to install (Azure/AES)
• Readme
• Security.md
• Example app
• CLI
• Init container

See an example here.
Need to add a CI task that:

• Produce the swagger
• Upload it to SwaggerHub

There is a bug with token review implemention, results in kubernetes client throwing an exception.

Nice project! Impressive and useful

Question: In k8 native secret I can have
name: secretsname:
key1:saaa,
key2:2222

Does kamus support this option?

I suggest to add -o, --output version to save the encrypted secret to file in specified path.

Due to the sensitivity of the communication, it worth enabling TLS for in-cluster communication, and block non-https traffic everywhere. See this SO question for options, but look like we'll have to handle TLS in Kestrel, without TLS termination.

• Add support for more tenants
• Run it by as dotnet tool or az cli extension.

I wanted to use kamus along with aspnetcore's IConfiguration, so I tried doing this:

encryptedSecrets:
  ActiveDirectory:ClientSecret: blablabla

But looks like that's invalid yaml (or at least kubernetes/helm don't like it).
The environment variable configuration loader supports ActiveDirectory__ClientSecret but not the json file loader, so that won't work either.
Basically if the init container had support for nested json I think this will all be okay.
What are your thoughts on supporting something like this?

There does not seem to be a way to leave it beside docker stop or letting it finish
This is probably a dockerfile issue, but this is really annoying when you realize you have made a typo :X

Inlining something like -----BEGIN PRIVATE KEY-----<some key>-----END PRIVATE KEY----- Isn't supported by the current input

All the logic should be moved into the CLI, and the container should use it directly.

Add KeyVault alternative that can be used for an easy start.
As part of the task, we need also to decouple the code from KeyVault.

Today we're using Wiremock for testing to mock Kubernetes API. Kind seems like an easy way to run Kubernetes, and maybe we can leverage that for testing.

The challenge - using minikube, maybe worth considering Travis or Codefresh as it might be simpler

Currently, the only way to use the decryptor is in the pod, but it should be able to write an init container.
The init container will read the encrypted values from config map, decrypt them and write them as a file to a mounted folder. The pod will read the decrypted value from the mounted volume.

• Official docker image for API
• Official NPM package for CLI
• Official docker image for init container

The current KMS provider is not visible for monitoring currently, which could cause a production issue, if someone will change it by accident. IMO we need to add a metrics on the isAlive that will report the current KMS provider.

When the required properties are not present in encrypt or decrypt request, the api returns 500 instead of 400 bad request.

I disabled them now because it's insecure - people can trigger builds that push images, or expose information. Need to investigate and decide how it is best to enable it again to test also PRs from a fork.

Add support for simple encryption key rolling:

• Endpoint to enable/disable expiration for a specific SA keys
• Export days to expiration per key on /metrics for easy monitoring
• Add support for re-encrypting values with the new key
• Add support for deleting old keys

Allow to connect to encryptor pod without ingress - view pod forward (similar to how Helm interact with tiller)

Currently, we're publishing only latest tag for the API. Need also to publish images with versioned tags.

For kubernetes cluster running on GCP. Look like there is an SDK for dotnet.
How do we handle authentication?

The current isAlive does not check the dependencies of the API.
The isAlive need to check:

• KMS provider health
• Kubernetes API access - that the decryptor can call TokenReview API

Currently isAlive just return true. we need to make it better.

CLI tests are based on fetching NPM module.
It's not suitable for PRs because we want to know that something is broken before pushing to NPM.

• Applicative audit logs from the API
• KeyVault Audit logs

• Encrypt request (with source ips)
• Decrypt request (source ip, SA identity)
• Failures

I suggest to use options instead of arguments in CLI encrypt command.
The encrypt command will be as following:

kamus-cli encrypt  \
   --secret super-secret \
   --service-account kamus-example-sa \
   --namespace default \
   --kamus-url <Kamus URL>

This approach will make the command line arguments order invariant and also we will be able to implement support for secret stored in file fixing #35.
For example for secret stored in file the command will be as following:

kamus-cli encrypt  \
   --secret-file /path/to/secret-file \
   --service-account kamus-example-sa \
   --namespace default \
   --kamus-url <Kamus URL>

I think it's more intuitive and self-describing command format.

• Project
• Namespaces
• Builds

Can be done using dotnet tool. Enable simple encryption utility.

This means that when a service account with the same name is created, the same key will be used.

Many existing applications running on Kubernetes relays on secrets to store sensitive data - which make Kamus unusable. This can be solved with a CRD that is wrapper around secret, something in the following format:

apiVersion: v1
kind: KamusSecret
metadata:
  name: mysecret
  namespace: default
  service-account: default
type: Opaque
data:
  username: <encrypted data>
  password: <encrypted data>

The CRD controller will use Kamus and the SA token to decrypt the value of the secret and create a real Kubernetes secret object from it.

We should not fail when someone asks to encrypt string which is too long, we should envelope encrypt that and return proper response.