I created a mysql service using the pcf's mysql tile from marketplace. My app connects to this service using the VCAP_SERVICES in the application-cloud propeties.
I want to secure this mysql service credentials using credhub.
For a user proovided service , I used credhub as below and was able to secure the credentials.
cf create-service credhub default credhub-service -c '{"username":"admin","password":"admin"}'
How can the same be achieved for services which are not user provided and are created using the PCF tiles from marketplace.(mysql in my case)
It's not something that an application developer can do. You need to talk to your operations team and have them enable that feature.
The relevant documentation can be found here: https://docs.pivotal.io/p-mysql/2-10/install-config.html#security-service-instance-creds
It explains how to enable that feature.
Related
I have an oData service that I will containerize & host over Azure container instance.
Now I want to use Azure API management to act as reverse proxy for my oData service and it should also be able to authenticate users/consumers.
I am looking to implement flow like this:
I have read few articles and I only got confused:
https://learn.microsoft.com/en-us/azure/active-directory/develop/authentication-flows-app-scenarios
https://learn.microsoft.com/en-us/azure/api-management/api-management-howto-protect-backend-with-aad
Above link expects you to have prior knowledge. I do not have any prior knowledge. What is the best way to implement this use case?
I have a Node.js application that need to read its configuration from Azure App.config.
When I go through the following example:
https://learn.microsoft.com/en-us/javascript/api/overview/azure/app-configuration-readme?view=azure-node-latest
I read:
AppConfigurationClient can authenticate using a service principal or
using a connection string.
How can I have AppConfigurationClient authenticate using MSI (Managed Service Identity) ?
You will need to use the #azure/identity package for javascript. More details can be found at
https://learn.microsoft.com/en-us/javascript/api/overview/azure/identity-readme
For managed identity, you will need to create a ManagedIdentityCredential and pass it to the App Configuration client. An example can be found at
https://github.com/Azure/azure-sdk-for-js/blob/#azure/identity_2.0.4/sdk/identity/identity/samples/AzureIdentityExamples.md#authenticating-in-azure-with-managed-identity
You may also like to check out DefaultAzureCredential. It can fall back to different credentials (including managed identity) in different environments. Examples can be found at
https://github.com/Azure/azure-sdk-for-js/blob/#azure/identity_2.0.4/sdk/identity/identity/samples/AzureIdentityExamples.md#authenticating-with-defaultazurecredential
I made a simple Node.js application that is using Google Cloud's Speech to Text API.
I could successfully authenticate locally, but how do I authenticate in production while keeping the credentials privates?
P.S. My application is not using any other server than Google's servers.
The credentials necessary for making client calls are based on a strategy called Application Default Credentials. These can be found through an environment variable called GOOGLE_APPLICATION_CREDENTIALS if the variable is present. If the the variable is not set, then the default credentials can be used. The following article provides detailed guidance on this topic:
Setting Up Authentication for Server to Server Production Applications
If your client is running outside of Google on your own premises (and hence not in a Compute Engine or GKE cluster) then the thinking will likely be that the credentials are contained in a file that is itself content protected by local OS access permissions. For example, contained in a file which has read permission restricted to either the user that runs your application or group that the user is a member of.
You need to be more specific to get more accurate answers
====================
OK, it's all about how you control the permission of your service account and there is a note in that page: "If you are developing a production app, specify more granular permissions than Project > Owner. For more information, see granting roles to service accounts."
You should use a specific service account needed to use this service. I don't have the particular role name(something like AutoML Viewer or Editor), and you need to test a minimum workable role in your Dev ENV.
After which, you can deploy your service into PROD and make sure the key with a 0400 file. So more or less the account can use limited service as expected
I am trying to deploy the Spring Cloud Data Flow Server to an enterprise Pivotal Cloud Foundry instance using an application manifest.yml.
My first concern is externalizing the SPRING_CLOUD_DEPLOYER_CLOUDFOUNDRY_USERNAME and SPRING_CLOUD_DEPLOYER_CLOUDFOUNDRY_PASSWORD properties from the manifest so I'm not storing them in plain text in version control. Is there a best practice to accomplish that? Where does that fit into the workflow of deploying a Data Flow Server and associated Streams/Tasks? My initial idea is to create a new Cloud Foundry user for the Data Flow Server that can deploy applications to the org/space I am using, then potentially use Spring Cloud Config to inject the credentials into the env. Is that a typical solution?
My second concern is requiring TLS/HTTPS for all of the Data Flow Server's web endpoints. I again attempted to omit the properties concerning the key store locations from the manifest in the SPRING_APPLICATION_JSON env entry, but that again caused initialization to fail. Does the Cloud Foundry Java buildpack have a standard location for those certificate stores, or is that specific to my Cloud Foundry instance? I also want to redirect all HTTP requests to HTTPS? Do I need to create a custom build of the Cloud Foundry Data Flow Server to do that?
Thanks for any help.
UPDATE:
Based on other SO posts, I have now resolved that I do not need to enable HTTPS/TLS from the Data Flow Server config in its embedded Tomcat server because it is sitting behind Cloud Foundry's proxy. However, I cannot see a way to require and redirect to HTTPS endpoints other than creating a customized build of the Data Flow Server for Cloud Foundry with the proper configuration.
You can refer the documentation for this here.
The Security section from the docs linked in the previous answer should be useful. I'll attempt to reply few specific questions.
I'm not storing them in plain text in version control
A few of our customers use Config-Server + Vault integration for encrypted password credentials.
My initial idea is to create a new Cloud Foundry user for the Data Flow Server that can deploy applications to the org/space I am using, then potentially use Spring Cloud Config to inject the credentials into the env. Is that a typical solution?
This whole experience will be automated with e2e OAuth/SSO workflow with Spring Cloud Data Flow's tile, which will be available as a BETA tile by this month. There won't be any clear-text passwords - everything will be OAuth token driven, and the service-broker will control the lifecycle of SCDF's service-instance. Please reach out to PCF account rep and we would gladly add you to the BETA program.
I have two applications:
MVC Site (User-facing Web App secured via OAuth -> Google)
Web API Site ("Private" Web Services)
These are hosted in an App Service Plan in Azure. These web services will only be consumed by my own applications - I don't need to worry about outside consumption. In fact, I specifically don't want outside consumption. My Web App is using OAuth to Google - that shouldn't matter here.
So to get to the heart of my question: My web services currently have no authentication/authorization model in the code but I don't want it just publicly available to anybody. On prem, we just lock this down via IIS using Windows Auth and set the service account for the consuming web app to run as a user that Windows Auth allows access to. I'd like to do the equivalent in Azure.
I understand Azure isn't exactly the same but I have to believe this is possible. I have even gotten my web services locked down the way I want using the settings in the Authentication/Authorization tab (I can try to navigate to it but I only get my Swagger UI once I login with a valid organizational account). So half of my battle is solved but I cannot figure out how to do the other half - the equivalent of setting the service account for my consuming MVC application to run as.
Can I do this via the portal without having to code specifically to this scenario? I'd really like a PaaS-level or IaaS-level solution for the security portion of consuming the above locked-down services. I'm also open to other avenues if I'm going down the wrong path in having a PaaS or IaaS security solution to this problem. I'm not against making code changes - we did have a one-liner in our RestSharp code to engage Windows Authentication, but the bulk of the work/configuration was outside of code and that's what I'm going for here.
If going the IaaS path you can host the application inside of an VM in the exact same way as you did before when running it directly on-top of IIS. The benefit is that you can get running the same way as before but you will still need to manage the VM; i.e install updates and take care of its security.
However, if you want to have a PaaS solution, then you need to modify the code of your front-end application to pass on the authentication token to the back-end API, assuming the back-end accepts the same authentication as the front-end. See https://azure.microsoft.com/en-us/documentation/articles/app-service-api-dotnet-get-started/ as an example on how to pass on authentication information from one app to another.
Alternatively you can use the app identity to make calls to your back-end API. This way the calls are not related to any user but are instead done in the context of the app. See https://github.com/Azure-Samples/active-directory-dotnet-daemon for more details on how to set it up, both configuration and needed code.
If you want to allow your users to sign-in using their Google accounts then you could handle authorization to your API using the app identity (second alternative above), assuming the API is independent of the requesting users identity.
Enabling authentication for a Azure Web App directly through the menus in the Azure Portal adds Azure AD authentication in-front of your application and require your to pass an access token generated by Azure AD to your API for it to work.