Other than AWS Console, there are multiple ways to access the AWS Services.
AWS CLI(awscli/AWSPowershell)
AWS SDK
REST API
Out of these three methods which is the most secure one?
Consider your thinking by the way - If you are working with AWSCLI, you need to store the credentials by using the command aws configure.
I know, without passing the credentials(AccessKey and SecretKey) for SDK,CLI and API, we cant access the AWS Services. But I hope still some other way will be there to access/manage the services.
In the end all of these ways call the AWS APIs, so from that perspective they are equally secure.
There are differences in the use of features of the APIs though. While the AWS CLI supports MFA authentication, only some SDKs do (e.g. boto3 does, the aws-sdk-js doesn't yet) and for accessing the APIs directly you would have to implement that yourself.
All of the methods mention have a similar degree of security. Based on how you store and use credentials, might affect the actual security strength.
Related
we use Aws Api Gateway to protect our apis.
We want to create an sdk for developers. The idea is to have In app purchase in their apps and call our apis in order to start payment.
We are trying to have a way to connect machine from machine. The first machine will be an sdk integrated in Android games and the second will be our back end protected by the api gateway.
The sdk should have a the authorization to consume the api.
Today we don't know how to do it, even after discussing with many architects.
The sdk is not going to have user and password, because it is not a user, so no way to generate the classic access token.
How could we achieve this use case ?
Thanks
The sdk should have a the authorization to consume the api. Today we don't know how to do it, even after discussing with many architects.
There are three possible ways to have a protected API Gateway. AWS Cognito and AWS Lambda. The third option, API Keys, is a little bit different than the previous two.
With Cognito, you create user pools and API Gateway automatically handles authorization when a request is received.
With Lambda, you create your own custom authorization logic.
I generally prefer the Lambda approach due to the ease of use but it depends on the use-case.
With the API Key option, you create API Keys for specific routes and API Gateway checks them through the request headers. I think any use-case that requires this can be handled with the Lambda option as well.
What you are describing doesn't sound difficult to achieve.
You will generate an API key and you will give them to the developers that will use your API.
In your SDK, you can accept the API key as an initialization parameter and provide it in the requests to API Gateway.
I have a private S3 bucket with lots of small files. I'd like to expose the contents of the bucket (only read-only access) using AWS API Gateway as a proxy. Both S3 bucket and AWS API Gateway belong to the same AWS account and are in the same VPC and Availability Zone.
AWS API Gateway comes in two types: HTTP API, REST API. The configuration options of REST API are more advanced, additionally, REST API supports much more AWS services integrations than the HTTP API. In fact, the use case I described above is fully covered in one of the documentation tabs of REST API. However, REST API has one huge disadvantage - it's about 70% more expensive than the HTTP API, the price comes with more configuration options but as for now, I need only one - integration with the S3 service that's why I believe this type of service is not well suited for my use case. I started searching if HTTP API can be integrated with S3, and so far I haven't found any way to achieve it.
I tried creating/editing service-linked roles associated with the HTTP API Gateway instance, but those roles can't be edited (only read-only access). As for now, I don't have any idea where I should search next, or if my goal is even achievable using HTTP API.
I am a fan of AWSs HTTP APIs.
I work daily with an API that serves a very similar purpose. The way I have done it is by using AWS Lambda functions integrated with the APIs paths.
What works for me is this:
Define your API paths, and integrate them with AWS Lambda functions.
Have your integrated Lambda function return a signed URL for any objects you want to provide access to through API calls.
There are several different ways to pass the name of the object(s) you want to the Lambda function servicing the API call.
This is the short answer. I plan to give a longer answer at a later time. But this has worked for me.
Say you have a bunch of on premise applications (that are your potential publishers).. can we have them (sitting in some private network), publish message on to an AWS eventBus/eventBridge, so that the target subscribers can take it forward from there... Does hybrid AWS help here?
If so, can you share some links on achieving the same
That should be very straight forward - you can use the put events endpoint of any AWS SDK for EventBridge.
You'll need an IAM user with which to call the API via access key/secret key.
From a networking perspective, you'll need to be able to hit the AWS API endpoints.
Here's the method to use in Python.
https://boto3.amazonaws.com/v1/documentation/api/latest/reference/services/events.html#EventBridge.Client.put_events
I am going to use Amazon S3 Infrequent Access. I have played around and found that it is possible to access this service in two ways.
Making Requests Using the REST API. This way looks pretty simple and clear.
Using Amazon API gateway. I am not big expert in this service and one different that I have found that payload size is limited to 10 MB.
What other advantages/disadvantages has using Amazon S3 Infrequent Access via Amazon API gateway?
If you are going to use Amazon S3, then you should call S3 directly. This can be done via the REST API or via AWS SDKs for most popular programming languages.
You can also use the AWS Command-Line Interface (CLI), which makes it possible to write scripts that can call the AWS API.
Amazon API Gateway allows you to create your own APIs that can call an AWS Lambda function or your own application. It should not be used to call Amazon S3 unless you are trying to Create an API as an Amazon S3 Proxy, which is a rare situation.
I'd like to run some stateless Java services on the Bitnami stack on AWS that will be consumed by apps... and of course to access these I'd need some type of authentication and authorization.
Previously with this type of architecture I've chucked an API gateway in front of them, to which the developer would subscribe. And AWS provides an API gateway, nice.
HOWEVER, while reading up on how to set this up on AWS I came across 'AWS Cognito' which is supposedly designed specifically for this same purpose.
So my question is are these two solutions comparable - are they doing the same thing?
And if-so, then what are the pros and cons of each, when would choose one over the other?
Basically because you are targeting the user level you should use Cognito; as it does provide you with authentication, reseting passwords for the user, and of course
signing up workflow. Moreover it provides user information to the admin, as well as two factor authentication, by using the user's mobile phone.
If you want to authorize the application to use an api then you use the API Gateaway.
The Cognito, is designed for user interaction it has an api for Java, JavaScript, iOS, and Android, so you can
implement the interaction with it at any level; as you wish. You also not getting changed if your user base is less than 50k.