I am currently working with a feature in our Ionic/Backand app that needs to access data from an external database (RedShift Cluster). I am thinking of the best way possible to accomplish this, and since we are using Backand as our backend, I thought if it was possible to make an action that could access RedShift Cluster and make SQL queries to it. Any help would be appreciated. Thanks!
Here is one option is
adding a generic lambda function to access AWS redshift,
Use AWS API Gateway to expose this lambda to Back &, (it is as secure as you want it to be, utilizing API key and AWS secret and access tokens of the IAM user)
Then calling this API in Back& server-side JS action by using $http object is a breeze
Related
My database is hosted in Cloud SQL, and how can I secure my database to from unauthorised entities to access.
How should I protect my database??
PS: I have seen suspicious activity on my database.
Google has written an extensive blog post on how to secure a database here.
One of the most important things that you should consider is going by the Least Access principle. This can be achieved easily by the IAM tool that Google Cloud Platform has for this.
Also, if your Cloud SQL instance has a public IP, you should consider using SSL/TLS to encrypt your data.
Last but not least, if your database was deployed with a default login, you should make it a top priority to change or disable that account.
I am working on an API project and it is going to be exposed to members of our system. We need to secure our API using API key.
When the API is invoked, we need to know which member is invoking the API.
So we need to map the key with the member some how.
I am wondering what is the best way to manage the keys. Following are the options we are aware of
For each member, keep the API keys in our backend system and manage the key in our backend and once key is changed, manually update it in API gateway
Whenever key is changed in backend system, invoke the AWS API gateway rest service to update the key in API gateway
Any other options( not looking or OAuth2 like complex key management solutions)
Api Gateway API Keys are not used for authentication but identification. Read the last pargraph here. Judging from your question that you need to know which member invokes the API Gateway etc. means that you most likely need to implement an authentication system and the best candidate here is AWS Cognito. Use the right tool for the job and don't try to reinvent the wheel.
It seems as though an AppSync project can only be configured with one Authorization type (API_KEY, AWS_IAM, etc.). I'm using AMAZON_COGNITO_USER_POOLS as my primary type, but I also have a (Node.js) client that I want to provision with API_KEY access.
Is this possible?
If not, can you suggest any alternatives?
The answer by Rohan works provided you don't have subscriptions; if you do have a subscription in one AppSync endpoint and mutate data in another AppSync endpoint then while the data behind the scenes is updated, the subscription won't update (which makes sense, as the subscription is a attached as a listener within an AppSync endpoint). Until AppSync supports multiple methods you might want to give IAM a try; there's some details here on how to get it to work with Cognito in app + a Lambda. The example there is in python but for node.js you would generate signatures with something like https://www.npmjs.com/package/aws4 . The same method would work if running your node.js client elsewhere provided you generate some API keys
There are two approaches to solve for your use case.
You can provision a separate AppSync endpoint (you can create up to 25 per region within an AWS account) with the same schema and configure it with a different authorization scheme. Use this approach only if you need hard isolation between the endpoints.
As of May 2019, AWS AppSync supports multiple authorization schemes for a GraphQL API. You can enable AMAZON_COGNITO_USER_POOLS as the default auth scheme and API_KEY as the additional auth scheme. This is the recommended approach and also works with subscriptions, which addresses Matthew’s concern in another answer.
As of May 2019, AWS AppSync announced the support for multiple auth types in the same API. https://aws.amazon.com/blogs/mobile/using-multiple-authorization-types-with-aws-appsync-graphql-apis/
I need to make an API call from post trigger of Azure DocumentDB.
I tried calling external APIs - but found that such calls are blocked in DocumentDB. If I host an API on Azure's same account will that API is allowed to be called from the post trigger ? If not what can be the alternatives.
Server-side code runs in a sandboxed environment and cannot make external calls. You can, instead, make the same call from your client after your request is acknowledged by the service (indicating your post-trigger succeeded/failed).
DocumentDB now supports a private preview of server side change feed. Using this model you can pull down all the changes from a DocumentDB collection and execute custom logic to perform desired post processing like invoking web services.
Please email askdocdb at Microsoft dot com if you want to learn more about this pattern.
In server-side scripts you can use all JavaScript functionality and CRUD/Query API for DocumentDB. Other "hosting" API is not exposed. For instance, JavaScript by itself doesn't have built-in support for file system or web API, functionality like needs to be provided by host (IE, cscript, etc). DocumentDB doesn't provide additional API other than CRUD/Query API.
In MongoLab you generate an API key and then anyone can access your database using REST API.
Usual case is to use the REST api directly from Ajax clients.
But this gives anyone complete write access to your database, which is security hole.
Is there a way to generate an API key which will give READ ONLY access to the database
Currently, all API keys have read and write access to the databases associated with the user's account. If you need to expose a read-only API we recommend building your own with one of the many frameworks available like Express or Sinatra.