I want to have a per client namespace and storage in my kubernetes environment where a dedicated instance of app runs per client and only client should be able to encrypt/decrypt the storage being used by that particular client's app.
I have seen hundreds of examples on secrets encryption in kubernetes environment but struggling to achieve actual storage encryption that is controlled by the client. is it possible to have a storage encryption in K8s environment where only client has the knowledge of encryption keys (and not the k8s admin) ?
The only thing that comes to my mind as suggested already in the comment is hashicorp vault.
Vault is a tool for securely accessing secrets. A secret is anything
that you want to tightly control access to, such as API keys,
passwords, or certificates. Vault provides a unified interface to any
secret, while providing tight access control and recording a detailed
audit log.
Some of the features that you might to check out:
API driven interface
You can access all of its features programatically due to HTTP API.
In addition, there are several officially supported libraries for programming languages (Go and Ruby). These libraries make the interaction with the Vault’s API even more convenient. There is also a command-line interface available.
Data Encryption
Vault is capable of encrypting/decrypting data without storing it. The main implication from this is if an intrusion occurs, the hacker will not have access to real secrets even if the attack is successful.
Dynamic Secrets
Vault can generate secrets on-demand for some systems, such as AWS or SQL databases. For example, when an application needs to access an S3 bucket, it asks Vault for credentials, and Vault will generate an AWS keypair with valid permissions on demand. After creating these dynamic secrets, Vault will also automatically revoke them after the lease is up. This means that the secret does not exist until it is read.
Leasing and Renewal: All secrets in Vault have a lease associated with them. At the end of the lease, Vault will automatically revoke that secret. Clients are able to renew leases via built-in renew APIs.
Convenient Authentication
Vault supports authentication using tokens, which is convenient and secure.
Vault can also be customized and connected to various plugins to extend its functionality. This all can be controlled from web graphical interface.
Related
I am developing a web application using NextJS. I am using firebase, sentry.io and infinite scroll in my project. When the application first runs, my data from the backend comes as server side. If the user scrolls, my new data is necessarily brought as a client side. I defined my key in the .env.local file with the prefix NEXT_PUBLIC since this API will be requested on both client and server sides.
Wouldn't defining it as NEXT_PUBLIC show my api url in the network?
I need to collect events with firebase for user actions. I have to access Firebase as client side. That's why I define my keys with the NEXT_PUBLIC prefix. For example: NEXT_PUBLIC_API_KEY
In such a case, my api key will appear on the network again. Isn't this a security issue?
How can I hide Firebase API Key?
I collect the errors that occur in the project with sentry.io. Likewise, I need to access sentry.io as a client side. When I perform the above scenario, users will access my API key.
If the secrets we define as NEXT_PUBLIC become public, what is the logic of defining them?
I need to request client-side for Infinite scroll and firebase, how can I secure the secrets I use at this point?
I will deploy my projects with docker. Where should I specify these env variables?
Well you can use Google Cloud Secret Manager to store your keys and you can use the Client Library to fetch the keys as you want.
References:
Secret Manager Docs
Secret Manager Client Librarirs Docs
I am using firebase and my backend API to get data for my APP.
The api requires a GCP key from access. This key expires every 90 days. So, I cannot store the key in the client/phone.
Need some ideas of where can I store the key.. I tried Firebase remote config and it works but the Firebase documentation said that sensitive data should not be used .
Creating a backend service that return the keys will not be secure as anyone can call the service,,
Need some suggestion. Is Firestore/Realtime database an option. The app will only read the data. However when the data changes(new keys) the App should get the latest.
Thanks for any suggestion
While distributing a private API key to the app at runtime through a mechanism like Remote Config, or a cloud database, may reduce the risk of it being intercepted, it is not enough to deter a sufficiently motivated malicious user. That's why the Remote Config documentation recommends against it, and the same applies to other distribution mechanisms (such as the databases you mention).
If this is a private API key, you should not use it in client-side code, period. That's really the only solution. When you use it in client-side code, a malicious user may get access to it and then abuse the backend service that is protected by the private API key.
Private API keys should be kept private, and only be used in a trusted environment (such as your development machine, a server you control, or Cloud Functions). When you allow users of your app to make calls through that private environment (by defining your own API for them), you will have to secure that end point yourself to ensure only authorized users can access them.
I am unable to find anything that explicitly states that GCP's Memorystore offering (redis) is encrypted at rest.
This document states that "Data at rest is encrypted by default in all Google Cloud Platform products. Read about the granularity of encryption by product.(link)"
https://cloud.google.com/security/encryption-at-rest/
When I click that link and it lists the granularity, however, it lists the specifics for many services, but does not list Memorystore.
https://cloud.google.com/security/encryption-at-rest/default-encryption/#granularity_of_encryption_in_each_google_cloud_platform_product
Is the data in a GCP Memorystore instance encrypted at rest?
Cloud Memorystore for Redis does not currently support persistence. Therefore there is nothing to encrypt at rest.
We are planning on moving away In our dev environment, we are in a situation where we need to issue certificates to salt minion clients using Vault.
Current salt module supports sending plain kv values to minions but nothing except that. Salt don't even support any auth methods except default tokens while we are looking to implement Vault's AppRole for authentication,
https://docs.saltstack.com/en/2017.7/ref/modules/all/salt.modules.vault.html
we have so far followed this guide to setup environment https://backbeat.tech/blog/secure-servers-with-saltstack-and-vault-part-1 but it isn't as of much help since our development has different requirements. I want to ask if there is any implementation of Vault + Salt which would allow us issue private certificates to salt minions using hashicorp vault and use more sophisticated way of authentication instead of just token?
Thanks in advance.
use more sophisticated way of authentication instead of just token?
There is AppRole support available on v2018.11 branch. You can add it in your salt as a new module instead of overwriting original vault module.
I want to ask if there is any implementation of Vault + Salt which
would allow us issue private certificates to salt minions using
hashicorp vault
You can use vault module for salt-stack to create your PKI. It allows you to write to vault PKI backend using vault.write_secret execution module. Something like,
salt-call vault.write_secret "<pki_backend_name>/issue/<role_name>" common_name="<___>" ttl="100h" format="pem"
or from a state,
{% set generate_certificate = salt['vault'].write_secret("<pki_backend_name>/issue/<role_name>", common_name="<___>", ttl="100h", format="pem") %}
I have written this guide on how you can use vault to generate PKI, it can come handy.
Hope it helps.
The documentation shows how to connect using Storage Account Key:
https://learn.microsoft.com/en-us/azure/storage/files/storage-how-to-use-files-windows
That does work. However, I'd like to mount file storage using read-only SAS token.
Is this possible?
is this possible?
Unfortunately, no. We must set the storage account key when mounting Azure File shares, everyone who has storage account and account key will have full permissions to manage and operate file shares. From the feedback we could know that Microsoft has no plan to do that.
At the moment, Microsoft does not have plans to support SAS tokens with SMB access. Instead, we are looking into supporting AD integration for mounted file shares.
It's possible on different approach and secure. You still use the mount cifs (net use windows) but you stored the credentials in the key vault. You should mount this on the bootup (with systemctl) using the technique of curl to get the credentials. You need to allow key vault access policy on the vm, now this is tricky too to automate but it's possible.