I wondering how to encrypt information in appsettings.json in asp.net core 2.0. I am looking for a way to encrypt connectionstring and other credentials or sensitive informations that can be store in appsettings.json in a production environment. Users secrets is only recommand for development purpose so they don't fit that requirements. Also i can't use Azure Key vault.
While not encrypted, you can use environment variables to store your sensitive information instead of including it within your appsettings.json file. This allows you to use user secrets in development and environment variables in production
If you're using Azure it will be under Application Settings.
Related
In my company, we have an internal Security Token Service consumed by all web apps to validate the STS token issued by the company central access management server (e.g BigIP/APM). Therefore the same endpoint for token validation REST API has to be repeatedly set as an environment variable in Deployment Configuration for each individual web app (Openshift project). So is an ES256 public key used by each web app for validating JWT token.
I'm wondering if there exists a way to set up a global Environment variable or ConfigMap or anything else in Openshift for these kind of common, shared settings per cluster such that they can be by default accessible for all web apps running in all PODs in the cluster? of coz, each individual Deployment Config should override these default values from the global settings at will.
Nothing built in. You could built that yourself with some webhooks and custom code. Otherwise you need to add the envFrom pointing at a Secret and/or ConfigMap to each pod template and copy that Secret/ConfigMap to all namespaces that needed it (kubed can help with that part at least).
I'm wondering if there exists a way to set up a global Environment variable or ConfigMap or anything else in Openshift for these kind of common, shared
When it comes to Microservices it is a good practice to share nothing and avoid "tight coupling". Its typically not good to have global variables.
This will be difficult when you want to evolve and maintain it. Keys are something you regularly should rotate.
In my company, we have an internal Security Token Service consumed by all web apps to validate the STS token issued by the company central access management server (e.g BigIP/APM).
So is an ES256 public key used by each web app for validating JWT token.
When you receive a JWT token, you should inspect the iss (issuer - the value can be an HTTP URL) claim, and if you trust the issuer, you typically can find an OpenID Connect Discovery endpoint where the issuer publishes Json Web Key Set with keys to validate the token.
With this architecture, you have a central service that issue tokens - and also publish keys to validate them. So no need to distributed them in another way - no shared variables. Now you also have a single place to rotate the token, so it becomes more easy to maintain.
I have an ASP.NET Core app that I deploy in a containerized manner to Azure Kubernetes Service (AKS) and when running just a single replica of the app - it is functional and works as expected.
However, when I run multiple replicas - I run into am error - “Unable to protect the message.State” from the OIDC provider.
Upon further research I have figured out that using ASP.NET Core Data Protection as depicted here is the solution -
https://learn.microsoft.com/en-us/aspnet/core/security/data-protection/configuration/overview?view=aspnetcore-5.0#persisting-keys-when-hosting-in-a-docker-container
However - the above link does not expand upon the usage pattern of it while storing the key in Azure Key Vault. Assuming I have protected my keys in AKV how do I actually get to use it in my app? Is there sample or guidance on this aspect?
First of all I would recommend that the same client instance (With AddOpenIDConnect(...) is the same that also handles the callback from your Identity Provider (/signin-oidc). The state parameter that it sets when it first redirects you to the identity provider must match the returned response (for security reasons).
To make sure that issued cookies in the users browser is valid all the time, you need to make sure:
All client instances uses the same data protection encryption key
The key is the same during redeployment.
You can for example store this key in Azure Key Vault, SQL-Server or somewhere else.
btw, I did a blog post about the Data Protection API here and how you could store the key-ring in AKV as well.
my connection string in user secret
No problem at local
but is publish and upload in server error
ArgumentNullException: Value cannot be null. (Parameter 'connectionString')
user secrets is only for development and not intended for production.It doesn't encrypt the stored secrets and stored in a JSON configuration file in the user profile directory.
For production , usually you can use JSON file(appsettings.json/appsettings.{Environment}.json), environment variables, and Azure Key Vault(which is recommended), please read below article for more details about configuration providers in asp.net core :
Configuration in ASP.NET Core
It seems the connectionStrings section is not yet configured at production machine. So you must store connection strings into Web.config file at production machine.
Connection Strings and Configuration Files
Besides that, you can protect the configuration by encrypt it using protected configuration.
Encrypting Configuration Information Using Protected Configuration
User secrets used for development security and it doesn't transfer/publish with your app (to GitHub or to IIS), they are stored in your local profile. If you are looking for securing your credentials & sensitive data the better way is to use Azure Key Vault (see Manage User Secrets)
I have an Azure File storage folder and I would like to have a simple HTTP Basic User/Pass authentication on it and be able to list the directory contents of that directory upon successful authentication.
I know that there are Shared Access Signatures but that's a different security approach.
This is so simple scenario but yet I cannot find a solution to it...
What I want to have is just a simple (bucket) folder that is going to be available over HTTP Basic Auth through the browser externally.
Does Azure File Storage support basic authentication?
At this time, Active Directory-based authentication and access control lists (ACLs) are not supported.
Azure Files supports identity-based authorization over SMB (Server Message Block) through Azure Active Directory Domain Services. Your domain-joined Windows virtual machines (VMs) can access Azure file shares using Azure AD credentials.
Do anybody know if there is any sort of API available for Cyber-Ark Privileged Identity Management to integrate it with an enterprise applications?
I think the answer might be 50% yes, 50% no. Definitely Cyber-Ark offers web services and an API for their Vault objects, so you should be able to retrieve passwords from the Vault from a trusted application. There is a paragraph of sales information on Cyber-Ark's website:
Cyber-Ark's comprehensive SDK provides an interface to the Vault objects that you can use to develop custom solutions that work with the Vault. Cyber-Ark provides a variety of SDK such as Command Line Interface, ActiveX API, .Net API and Web Services API
But beyond working with their Vault objects, I'm not entirely sure. I'm currently looking for more information on their Vault web services, and I think I need to register to be a Partner to get that information. I'll post a follow-up if I learn anymore.
You are suppose to purchase an API license per server to have read-only access to the vault for authorized applications.
They provide Java, C#, etc. libraries and you place authorization key material on the server to enable it access.
It is called CyberArk Application Identity Manager, an entire sub-product.
The only reference I could find:
http://lp.cyberark.com/rs/cyberarksoftware/images/ds-application-identity-manager-10-20-2014-en.pdf
CyberArk created Conjur. It is open source and free. It contains its own Vault and is intended for dynamic Application Access Management. In particular, Conjur and its upgrade Conjur Enterprise should secure the complete DevOps pipeline. The paid version can be integrated with the Vault solution (the PAS Core solution of CyberArk).
For static applications, CyberArk has the Credential Provider, Central Credential Provider and ASCP (I forgot the full name of it now). These solutions are agent based while Conjur is agentless. Because they are agent based, they are only intended for environments with comparatively slow changes as an agent needs to be installed on every server in order to provide the credentials from the Vault.
These solutions have REST API, CLI and SDK capabilities.