/ALKS

Air Lift Key Services - AWS Temporary Federated Key Management

Primary LanguageJavaGNU General Public License v2.0GPL-2.0

#Air Lift Key Services (ALKS)

##Summary:

Filling the gap for key services between what Amazon provides and the need for system admins/users to create manage temporary tokens to access AWS resources. The purpose of the tool is to automate generation of federated tokens on demand. It makes it easy for system admin's to manage, create and track issuance of these tokens. User validation is performed against LDAP and the application checks if user belongs to any of the LDAP groups before displaying respective options to generate keys.

##Features

###Generate session tokens

  • Create temporary tokens to AWS resources for a particular duration with click of a button.
  • Access is restricted through AD group assignment

###Authentication and Authorization

  • Use internal LDAP for Authentication and Authorization
  • VPC/VPN Connection to AWS account and on premise LDAP directory
  • Control user access through LDAP directory services
  • Admin role with elevated privileges
  • User is limited to create tokens using one of the roles which are based on the LDAP group they belong to.

###Auditing/Logging

  • Track issuance of tokens and history through logs within ALKS

###Security

  • Critical account data is encrypted in DynamoDB using client side encryption

###Design Constraints AWS SDK has a constrained policy length (2048 bytes) to generate tokens. Refer topic "Policy limitation Work around" below. Refer to the following document: http://docs.aws.amazon.com/STS/latest/APIReference/API_GetFederationToken.html

####Policy limitation Work around: As we know, long term keys are used to generate federated tokens. Currently we give complete access (admin level) to these long term keys so that we can generate temporary tokens with any level of access up until admin level. But for roles which have long policy document, we can create users with limited access. Example for cloud engineer role, we can create IAM user having cloud engineer level role and add it to ALKS. Using long term keys of this user, along with the admin level policy can be used to generate temporary tokens. The temporary keys generated by these keys will have access only to a cloud engineer level. Please check AWS documentation at the below link specifically words "The passed policy cannot grant more permissions than those that are defined in the IAM user policy."

http://docs.aws.amazon.com/STS/latest/APIReference/API_GetFederationToken.html

###Dependencies

  1. Dependency versions
  2. Other dependencies:

###Installation and Setup

  1. Get the project from git and setup as a Dynamic Web project. Make changes to the build path as needed.
  2. Update the properties file with all the configuration values and customized messages. Refer to properties file descriptions for additional details.
  3. Create a keystore file (alksopen.jck) to store your encryption keys for encrypting long term keys that will be stored in DynamoDB. You should save this file in src folder (or in the classpath). (I have included an example file whcih should be replaced)
  4. Authentication: This application uses core javax.naming.* package to validate users against LDAP. To identify an admin user, add a new AD group and update the messages.properties file. User should be part of the group to be recognized as an admin.
  5. DynamoDB: Create three tables with following columns
    • com.alks.table.accounts(accountNo -> HashKey)
    • com.alks.table.accountrolepolicy(id -> HashKey)
    • com.alks.table.accountidgroup(accountrolepolicy_id -> HashKey and adGroup -> RangeKey) Use java file (ALKSDynamoDBSchema.java) to create these tables. Change table names as per your company standards. Do sync the names in com.alks.model.db package.
  6. Setup users in AD (AWSG_ADMIN_ALKS - Admin user, AWSG_CLOUDENGG_ROLE etc)

###AWS Services/APIs Utilized

  1. AWS IAM Services
    • Get account details
    • List roles for an account
    • Generate federated tokens.
  2. AWS DynamoDB

###Application Functionality

  1. Login Screen: Users can login using their network credentials (UPN/password) to login. After successful login, user will be displayed with list of accounts and roles for which keys can be generated against.
  2. If the logged in user belongs to an Admin LDAP group, the user is identified as admin user and will have additional menu options to
    • View and Add/Update and inactivate accounts
    • View and Add/Update ARP relation
    • View and Add/Update ADG relation
  3. Accounts Screen: Accounts screen displays list of accounts that have been added. For security reasons secret key is not displayed. The ‘Inactivate’ button can be used to inactivate an account. Once account is inactivated, it will not be shown on any other screens either to generate keys nor to create new ARP’s or AdGroup relationship records.
    • Get account details
    • List roles for an account
    • Generate federated tokens.
  4. AWS DynamoDB

###Application Functionality

  • Login Screen: Users can login using their network credentials (UPN/password) to login. After successful login, user will be displayed with list of accounts and roles for which keys can be generated against.

Login Screen

Screen Shot Login

Home Screen

Screen Shot Home

  • If the logged in user belongs to an Admin LDAP group, the user is identified as admin user and will have additional menu options to

    • View and Add/Update and inactivate accounts
    • View and Add/Update ARP relation
    • View and Add/Update ADG relation

  • Accounts Screen: Accounts screen displays list of accounts that have been added. For security reasons secret key is not displayed. The ‘Inactivate’ button can be used to inactivate an account. Once account is inactivated, it will not be shown on any other screens either to generate keys nor to create new ARP’s or AdGroup relationship records.

Accounts Screen

Screen Shot Accounts

  • Admin user has option to Add/Update additional accounts. New account can be added by long term keys. Long term keys if correct, gets account number and account alias. Account number is a read-only field and alias can be changed if needed. Secret Key will be encrypted and stored.

Add Account Screen

Screen Shot Add Account

Note: In addition to having elevated privileges, these long term keys will need to have IAM read only access role, this is needed to fetch

  • All the roles for account.

  • Account number and alias

  • ARP(Account Role Policy) relation screen: This screen displays existing list of accounts AWS Role and policy relationships. This screen will be used to customize access rights to each AWS Role.

Account Role Policy (ARP) relation Screen

Screen Shot ARP

  • Admin user will have option to add new ARP record. User selects the account and AWS role and inputs the policy. The policy that is entered for the selected role will give respective access to the generated tokens. So within the application this policy will redefine access rights to the role selected but does not make any changes in AWS account.

Add ARP Screen

Screen Shot Add ARP

  • ADG(LDAP/Active Directory Group) relation screen: This screen will display all the relationships between the ARP (account role policy) and LDAP groups. If logged in user belongs to any of these LDAP groups that been mapped, they will have an option on the home screen to generate federated tokens in those respective account/role combination.

AD Group relation screen

Screen Shot AD Group

  • Admin Users can add new LDAP Group relationship by selecting a pre-populated accounts and respective ARP records created earlier. All LDAP groups are displayed to select from

Add AD Group relation screen

Screen Shot AD Group Relation

Additional Tips and customizations

  1. Convert to a Maven project
  2. Userid's created for the long term keys should not have '-' as this is used as a delimiter for display purposes

###References