We're a growing shop that has no real user management. It's come the time to have single-sign-on. We host everything in AWS with the exception of an in-house desktop server that basically just hosts a NAS.
I'm only slightly familiar enough with Active Directory that I could set up an in-house domain and have it federate users. I've read the FAQs on AWS Directory Service and just looking to get clarity at what it can and cannot do.
My goal is to have an AD that can manage users in AWS as well as in-house. I'm unsure if I can do both in AWS DS or if it's just to handle the AWS portion.
Per the FAQ: AWS Directory Service makes it easy for you to setup and run directories in the AWS cloud, or connect your AWS resources with an existing on-premises Microsoft Active Directory
Does this mean that even if I ran AWS DS I'd still have to host an in-house AD and join them to manage users in AWS as well as in-house? I'd like to avoid having to run one on-premesis since my goal is to get everything into AWS.
You can use AWS SSO to manage authentication to the AWS console and AWS CLI and it integrates directly with AWS Managed Directory Services, so you can have all your authentication in one place. Take care to create a "break glass" IAM account in case you have issues in AD, lest you lock yourself out of AWS and therefore can't manage the AD servers.
https://docs.aws.amazon.com/singlesignon/latest/userguide/connectawsad.html
Related
I have a simple shell script which issues several commands using awscli and displays information to the screen. It depends on having correct settings in ~/.aws/config and ~/.aws/credentials. I want to distribute it to about 10 users who have IAM accounts with limited privileges. However I don't want to use the shell - I want something cross-platform, easy to use for the users and easy for me to update. So I decided that I want to create a simple web application in JS instead, using the AWS SDK.
It seems that this use case is specifically supported by AWS, the first bullet point under "Common Use Cases" in What Is the AWS SDK for JavaScript? is "Build a custom console to AWS services in which you access and combine features across Regions and services to best meet your organizational or project needs" which exactly describes what I want to do.
The problem is that I can't find the relevant documentation on how to perform the user authentication. All the examples that I was able to find talk about some "Amazon Cognito" service and discuss much more complicated use cases, such as authenticating pools of external users through an external authentication provider and mapping them to IAM roles, which sounds too complicated for what I want to do. Is there a way to just authenticate the users that I have with their IAM user/password, and authorize them to access the AWS services based on their existing IAM permissions? Or is using Cognito, creating additional roles, etc. mandatory?
While writing this question I found out another question about AWS Amplify and now I'm even more confused. Is AWS Amplify what I would want to use?
You can write a web app using the AWS SDK for JavaScript that invokes various AWS Services. You do NOT need to use AWS Amplify to create a web app.
A Web application that uses the AWS SDK for JavaScript uses creds like any other AWS app. Here is an AWS tutorial that shows how to use the AWS SDK for JavaScript to write a basic web app that invokes the AWS SQS service. It will hopefully point you in the right direction.
Creating an example messaging application
This topic covers Prerequisites and other information, such as creating the required AWS resources, you need to know to write a web app using the AWS SDK for JavaScript.
Also - the link you referenced was the JavaScript V2 DEV Guide. Its better to use the AWS JavaScript V3 DEV Guide.
How in a work environment with different AWS environments say for example develop, staging and production is it best to store the AWS Access Key and Secret Key other than in the appsettings.json files in .Net Core? I know there is Secret Manager but not sure if that is the best way to store these two values. Looking for someone that may have done this specifically for production and how they handled this within their organization. Thanks for any information.
I believe that your application is running outside of AWS and that it needs to make API calls to AWS services, for example SQS. To make those API calls, your application needs AWS credentials.
Here are approaches for authenticating external applications in a machine-to-machine scenario. In your case, your client seems to need to be able to make arbitrary AWS service requests and that means using AWS signature v4 requests, signed using AWS credentials, which are ideally temporary, rotated credentials from STS rather than persistent credentials (such as IAM user credentials).
Typically, you would configure your application with a base set of IAM credentials that allow the application to assume an IAM role. That role itself, rather than the base credentials, would then give your application the permissions it needs to make SQS API calls etc.
The issue you face is how to securely store the base set of credentials. This is a problem that on-premise applications have had since day one, well before the cloud era, and there are various solutions, depending on the technology you're using.
Typically these credentials would be encrypted, not committed to code repos, and populated on the relevant, locked down application servers in some secure fashion. Some potentially useful resources:
Encrypting sections of a configuration file for an ASP.NET application
Use AWS Secrets Manager to store & read passwords in .Net Core apps
Securely store and retrieve sensitive info in .NET Core apps with Azure Key Vault
AWS Secret Manager securely stores your secrets until you retrieve them at runtime. If your going to be running your ASP.NET Core app in AWS, then AWS Secrets Manager is a great option, as it allows you to finely control the permissions associated with the AWS IAM roles running your apps.
Here are some faqs which were given from the AWS for secrets-manager service and which will clear your doubts also.
Here is the article which you can refer to for implementing secure secrets storage for .net core with AWS Secret Manager
AWS Transfer Family supports integration with AD Connector (https://docs.aws.amazon.com/directoryservice/latest/admin-guide/ad_connector_app_compatibility.html). As far as I understand, connectors are deployed in vpn-linked subnets that allows them to proxy calls to an on-premise Active Directory.
What exactly happens (what resources are created/updated under the hood) when I select AD connector as the authenticator for AWS Transfer? I'm specifically curious as to what changes are made in VPC to allow this integration.
In relation to AWS Directory Service, AWS Transfer does not seem to mutate your VPC. If you create an AD and then associate it with AWS Transfer, and take a look at your VPC, there is no new networking resources of any kind. Similar to other applications (https://docs.aws.amazon.com/directoryservice/latest/admin-guide/ms_ad_manage_apps_services.html), AWS Directory Services authorizes AWS Transfer to access your AD (in this case, connector) for Transfer logins.
I am trying to write an application in Python.
Through this application I want to create AWS Cognito users and provide services like user Sign-in, Forgot password, etc.
As I understand, boto3, is the standard Python library for accessing AWS APIs, from Python.
https://boto3.amazonaws.com/v1/documentation/api/latest/guide/quickstart.html
This library needs storing of AWS credentials ( Access key and secure access keys) on the host machine.
Can this be avoided?
I want to distribute this Python application to my users.
I am checking, if I can avoid this configuration of AWS credentials on every user's host.
Is there any alternative option to boto3 library?
If you absolutely need to access internal AWS API's you need to log in to AWS. Access keys is one way, it's also possible to use aws-adfs command line tool to log in though active directory, but that requires your AWS/AD administrators to do some additional setup on their side.
I would suggest looking into writing a client-server / web applications that would be hosted within AWS and only expose relevant functionality to authenticated users.
If costs are an issue for a hosted application, look into lambdas, as there you pay only for cpu/memory time. In case of setting management app it will probably not even exceed free tier.
both of them are used to authorize from company network to use AWS resource. I do not know what is the difference btw them.
AWS Directory Service for Microsoft Active Directory (Enterprise Edition), also known as AWS Microsoft AD, enables your directory-aware workloads and AWS resources to use managed Active Directory in the AWS Cloud. The Microsoft AD service is built on actual Microsoft Active Directory and does not require you to synchronize or replicate data from your existing Active Directory to the cloud.
see https://aws.amazon.com/directoryservice/
whereas STS:
The AWS Security Token Service (STS) is a web service that enables you to request temporary, limited-privilege credentials for AWS Identity and Access Management (IAM) users or for users that you authenticate (federated users).
see http://docs.aws.amazon.com/STS/latest/APIReference/Welcome.html
The AWS Directory Service is a full AD implementation which can "join" your in house servers. This would work better if there is a VPN and/or AWS Direct Connect in place. So replication occurs just as it would if you set up another Microsoft AD server
STS for linking your on premise accounts to AWS has some kind of shim software that is custom, running on premise. In the case you are asking about the local on premise environment has AD. The custom software deals with authentication against a local AD, then negotiates temporary creditials with the AWS account. AWS do custom software for this use case see https://aws.amazon.com/blogs/security/how-to-connect-your-on-premises-active-directory-to-aws-using-ad-connector/
So the difference between them is
AWS Directory Service sets up a new server on the cloud. This has to be linked to your on premise equipment to get it to work. It works better with a good link between on premise and AWS. Could be a better fit if your are running Microsoft stack on AWS
STS in this use case requires installing software on your on premise systems. There is also configuration to the AWS account