Dear Cumulocity community,
i am developing a microservice for Cumulocity which needs some secret information (private key). One requirement is to store this information in a secure way. Which means encrypted and only access able by the microservice? During my research I found the possibility to define secrets at kubernetes: https://kubernetes.io/docs/concepts/configuration/secret/
Unfortunatly I am not familiar with kubernetes. Do i have the possibility to define secrets by using microservice-package-maven-plugin? Can i use this “secret” at all in Cumulocity? Has someone already used “secretes” in a hosted microservice?
Thank you in advanced, best regards
Kubernetes secrets aren't all that secret. They're accessible by any administrator, for example. Think of them as being convenient rather than secure.
Once you create a secret in Kubernetes, you can inject it into a pod as an environment variable, or as a file path. Check out the secrets docs and best practices.
If you are running Kubernetes in AWS or GCP, there are better ways, find a way to hook into the csp's key management systems, and you can have much more secure secret data.
Related
I'm new to Hashicorp Vault. I am wondering if there is a way to take advantage of the SPIFFE protocol to automatically authenticate with Vault, so based on a vault client's mTLS certificate, a workload in Kubernetes/Istio can access Vault as a specific user (entity?) or group. The requesting k8s workload would only have access to Vault secrets based on its SPIFFE identity's Vault permissions.
I'm hoping that no Vault credentials (tokens, passwords, etc) would need to be passed and that access would be granted purely on the mTLS connection and the SPIFFE protocol. Is something like this possible? What are the options if Vault lives outside of the Kubernetes cluster (and therefore can't have an Istio sidecar)?
If what I'm asking is not possible, a less ideal solution would be to update the application code to somehow authenticate with Vault based on the pod's k8s Service Account. What are the options that Vault provides to do this type of thing? Are there any good resources regarding this?
I appreciate any advice you have to offer.
I have no knowledge about using SPIFFE for Vault authentcation, but I agree that it could be interesting (I'm not sure whether https://www.vaultproject.io/docs/auth/cert could help, but I never tried that).
As far as I know, the general way of integrating Kubernetes with Hashicorp Vault is described in https://www.vaultproject.io/docs/auth/kubernetes . It does not really matter where Vault is deployed: it can be inside the same Kubernetes cluster, in the same service mesh, or it can be a completely unrelated entity (e.g., a dedicated instance deployed on some random VM).
You basically define roles and policies on Vault, which are mapped to specific kubernetes service accounts and namespaces, and then the Kubernetes pod will be able to authenticate with the JWT that is associated to its service account.
Once Vault is setup and you can authenticate with Kubernetes pods, you can have any wrapper around it. People are trying to do this in different ways, but one possibility would be https://www.hashicorp.com/blog/injecting-vault-secrets-into-kubernetes-pods-via-a-sidecar . Personally, I'm using https://github.com/postfinance/vault-kubernetes because it fits my needs quite well.
The important part is setting up Vault to support Kubernetes properly: make sure to double check that first, before getting into any of these Kubernetes packages that try to fetch secrets.
I'm in the process of implementing IdentityServer4 into my ASP.NET Core web application, which will be deployed to a Kubernetes cluster using Continuous Deployment.
The documentation talks about adding signing credentials (AddSigningCredential) and most tutorials/guides demonstrate how to use this by loading a .pfx file from the file system, or by using the local certificate store and searching by the subject name.
Is there a commonly accepted way of storing, retrieving and rotating the signing credentials when deployed to a Kubernetes cluster with minimal intervention?
I think using a secret is the best option in Kubernetes.
K8s have a secret kind that can be deployed with other ressource, here is a link to the official doc: https://kubernetes.io/docs/tasks/inject-data-application/distribute-credentials-secure/
Or you could also use another secret manager , like Vault.
If I am not mistaken , I think it's the best practice.
Is there built-in support for enabling SSL on Azure Container Instances? If not, can we hook up to SSL providers like Lets Encrypt?
There is nothing built-in today. You need to load the certs into the container and terminate SSL there. Soon, we will enable support for ACI containers to join an Azure virtual network, at which point you could front your containers with Azure Application Gateway and terminate SSL there.
As said above, no support today for built-in SSL when using ACI. I'm using Azure Application Gateway to publish my container endpoint using the HTTP-to-HTTPS bridge. This way, App Gateway needs a regular HTTPS cert (and you can use whichever model works best for you as long as you can introduce a .PFX file during provisioning or later during configuratiorn) and it will then use HTTP to talk to your (internally facing) ACI-based container. This approach becomes more secure if you bind your ACI-based container to a VNET and restrict traffic from elsewhere.
To use SSL within the ACI-container you'd need to introduce your certification while provisioning the container, and then somehow automate certificate expiration and renewal. As this is not supported in a reasonable way, I chose to use the App Gateway to resolve this. You could also use API Management but that is obviously slightly more expensive and introduces a lot more moving parts.
I blogged about this configuration here and the repo with provisioning scripts is here.
You can add SSL support at the API Gateway and simply configure the underlying API over HTTP.
You will need the secrete key to execute above api method!
You can access the underlying API hosted at the Azure Container Instance. This method does not require jwt token as this is a demo api.
I apologize if I am asking something too obvious, but I as understand SSL should be used when making API calls to remote apps. This particularly important if you are using a password or API key in the calls so networking sniffing doesn't reveal the details.
Having said that, if I have a Cloud-hosted app, e.g. AWS hosted PHP script, that makes a call to a MongoDB database hosted by a third-party provider e.g. ObjectRocket, do I need SSL between the two?
Secondly, as I understand if both the apps are hosted on the same infrastructure, e.g. Heroku (which AWS-based) and a third-party MongoDB provider (if they use AWS of the same region) then SSL is redundant when connecting from a Heroku-hosted app to the the database as AWS will prevent networking sniffing.
Thank you for your help. I appreciate anyone who can provide some fundamental information here.
I am working on a HIPAA cloud project and am implementing a Key Store as a central repository for all of the key pairs for PHI(Private Health Information) encryption... I am not worried about the actual data because it will be encrypted at rest and in transit.
However when a worker or webrole needs to work with the data they need to decrypt and reencrypt it (if they do updates). That's where the key Store comes into play. However, I don't want this internal service exposed and I also need it to be SSLed, because sending keys in the clear, even inside a virtual network of roles wouldn't pass a security audit.
So any suggestions on how I can get a web or worker role to use SSL with an internal endpoint?
Thanks
I don't think you can. Internal endpoints are on a closed network branch, so https would normally be redundant (although I understand your compliance issues). I found this answer (to my question) very useful in figuring out the security of internal endpoints: How secure are Windows Azure internal endpoints? - see the more detailed post that Brent links to.