I'm building a Java application which needs to access the DynamoDB. The application is intended to be used by several end users (not all of them are trusted). From my understanding, in order to access the AWS service,the AWS credentials need to be loaded at runtime on end users' machine via several ways described at https://docs.aws.amazon.com/sdk-for-java/v1/developer-guide/credentials.html
However I don't feel it'll be safe to directly hardcode the access key and token into the application code, as this can be easily exposed. Given my end users don't have too much technology background, I don't want to add too many "pre-setup" steps before they can use the application.What will be best/feasible practise to distribute the credential to them?
Thanks for all opinions.
You probably need to be looking at AWS Cognito
An Amazon Cognito user pool and identity pool used together
See the diagram for a common Amazon Cognito scenario. Here the goal is
to authenticate your user, and then grant your user access to another
AWS service.
In the first step your app user signs in through a user pool and
receives user pool tokens after a successful authentication.
Next, your app exchanges the user pool tokens for AWS credentials
through an identity pool.
Finally, your app user can then use those AWS credentials to access
other AWS services such as Amazon S3 or DynamoDB.
Related
I’m coding a Firebase application.
The user can only read the database and the owner can write in the database to add some content.
The owner would need an admin desktop application to upload data on the database (storage and database).
Since the application is a C++ app I would use python to communicate with Firebase.
I wanted to use Pyrebase or python-firebase but unfortunately these projects seems not to support the new database Firestore…
The rest API could work but... only with the Firestore database part...
My only way to add content to Firestore and storage is then to use the admin sdk.
I know that the C++ applicaiton will be used only on the owner computer but I’m worried about getting the service account file.
What would be the best way to use safely the service account file?
I thought to:
Encrypt the file with a password and then ask the password every
time the c++ needs to use the admin sdk (which technology would be
better for this?)
Download the service account file everytime the app needs (but where
to store it safely in the cloud?)
In order to use the Admin SDK with a project, you must have access to the service account credentials for that project. And with those credentials, you have full and unlimited access to the project. You should only distribute the service account credentials to users who should have such access, typically the collaborators on the project.
For application level administrators that are not collaborators on the project, I typically recommend setting up an administrative dashboard with a server-side and a client-side component.
The server-side component runs in a trusted environment, which for me often is Cloud Functions, but can also be a server you control, or even your development machine. This is where you use the Admin SDK to perform application administration actions, which you then expose in an authenticated end-point that client-side applications can call.
The client-side component is what the application administrator uses. For me this is often a very simple web page, but it can also be any other technology you prefer, as long as it can call the end points you exposed on the server.
The key here is that the server validates that the user that calls it is authorized to do so, before executing administrative actions on their behalf. With this approach, you don't have to give the service account credentials to a non-collaborator, and can revoke the administrator's credentials if needed.
When we store the Service principal certificate/appKey in the VM (to access the keyvault), we could limit access to that file to just the user account running the program. Other users or accounts wouldn't have access to the secrets in keyvault.
When we use Azure Managed Service Identity to access keyvault from an IaaS VM, my understanding is that any user logged into the VM or any program running on the machine can access the keyvault secrets - is this true?
And if it is, doesn't that decrease the security in case one of the user accounts is compromised?
According to the article access Azure Key Vault, it seems this is true. If MSI is enabled, just need to invoke web request in the VM without e.g. appKey.
And if it is, doesn't that decrease the security in case one of the user accounts is compromised?
It should be, but the prerequisites of the access to the secret in the keyvault is the VM service principal was added as a role in Access control (IAM) and Access policies.
If you want to increase the security, you may need to remove the VM service principal in the Access policies, then it will not be able to access the secret, if you want to the service principal does not have the access to the keyvault at all, remove its role in Access control (IAM).
For more details, you could refer to: Secure your key vault.
Update:
From the doc #Arturo mentioned, it is the fact.
Any code running on that VM, is able to call the managed identities for Azure resources endpoint and request tokens.
I have an application that runs in a Service Fabric(SF) cluster and I wan't to access Key Vault from it.
The cluster hosts a number of applications and I want to give access to a Key Vault for my application without giving access to the other applications. By default an application runs under the same user as the SF cluster, but each applicatiuon has it's own unique name, mine has the name fabric:/application1.
My question is, is it possible to create an Active Directory application account for fabric:/application1 and grant access to the key vault?
I know it is possible to use the RunAs options in the SF manifest, but that requires me storing an encrypted password in the manifest/source code and I want to try and avoid this if possible.
AFAIK,
The only way to have this flexibility is using ClientID & Secret or Service Principal certificates and each application manage their own credentials.
Service Principal Certificate is already integrated to AD, but does not require the application, the user or the Host to be part of the domain, the only requirement is setup an user on AD to grant the permissions on Keyvault.
There are other solutions using AD integration, like Managed identities for Azure resources(Former: Managed Service Identity) but I am not sure if you are able to restrict access per application like you described, because the MI add this as a service in the node, so technically other applicaitons would have access as well, worth a try to validate if you can restrict this.
If you want to try this approach, you can use with Microsoft.Azure.Services.AppAuthentication for implicit authentication of the services running in your cluster, where the nodes are setup with Managed Identities extension like described here.
Something link this:
When you use the Microsoft.Azure.Services.AppAuthentication, the Step 2 will be handled by the library and you won't have to add much changes to your key vault auth logic.
When you run your code on an Azure App Service or an Azure VM with a
managed identity enabled, the library automatically uses the managed
identity. No code changes are required.
The following docs describe other options you can use for KeyVault Authentication.
PS: I've done other KeyVault integrations using Client Secrets and Certificates and they are secure enough, With Certificates you can store it on the managed store or with the application, I would recommend MI only if is a requirement for your solution.
I want to store some analytical information about the use of mobile apps into Amazon DynamoDb. I have the following requirements:
exactly one DynamoDb table per one mobile app
an app can do only PutItem method
all users of apps are unauthenticated (guests)
To provide to mobile apps a way to access a table in DynamoDb I see two options:
hardcode credentials with limited permissions into apps (permissions to do PutItem to a specific table);
use Amazon Cognito to get temporary credentials for unauthenticated users in runtime.
The second option Amazon strongly recommends as a much more secure. In my case a malicious user can either get access to hardcoded credentials or to a hardcoded identity pool ID with the same result: getting access to an AWS resource.
Question: does the use of Cognito in my case give any security improvements and if yes, how?
Cognito identity is totally free - you wouldn't have to pay anything.
Your point that using Cognito doesn't add any security to unauthenticated requests isn't correct. From the Cognito FAQs:
Q: How does Cognito Identity help me access AWS services securely?
Cognito Identity assigns your users a set of temporary, limited privilege credentials to access your AWS resources. You can use Cognito Identity to securely access other AWS services from your mobile app without requiring your AWS account credentials. You can also use the unique identifier generated for your app users in your Identity and Access Management policies. For example you can create a policy for an S3 bucket that only allows a particular user access to their own folder.
The same thing described for S3 can be done with dynamo - see this blog post for specifics.
I am new to Identity server but I found it quite easy to set up.
Our goal is to implement SSO down the line but at the moment we are just moving our authentication logic out of application.
It is going good except I have one confusion.
When I set up the Idsrv, I had to create admin user as well as token requesting user. This was to access and configure Idsrv.
For application auth, I have to use Idsrv as federation server as well and authenticate users against some Asp.Net data store.
Now there is already one data store where Identity server specific users are stored.
Should I be using same store for my application user auth and created/edit these users in that store? Or can I/should I create a separate database for application specific users and use both?
At the minute, I am authenticating application users against Idsrv store.
I am not sure if I am logically thinking in right way to split these two user sets and calling one as Idsrv specific users. (We will have Identity service separately deployed for each application)
Thanks for your help in advance.