Showing posts with label roles. Show all posts
Showing posts with label roles. Show all posts

Wednesday, April 2, 2014

IAM : AWS services not supported and tagging support

I often get the question of which services do not support IAM?  Some services and features do not support IAM and must use the AWS root account credentials:

  • Vulnerability Scanning Coordination Form
  • AWS Workspaces
  • Visibility of all Data Pipelines
  • Specific account management pages, such as account profile, AWS account security credentials, payment methods and management of consolidated billing 
  • AWS DevPay 
  • CloudFront keypair creation

A full list of supported services is here:
http://docs.aws.amazon.com/IAM/latest/UserGuide/Using_SpecificProducts.html

This page also provides a great list of IAM resource level permissions support, tagging, and STS.

Sunday, March 30, 2014

AWS IAM services and features that play a role when moving Oracle workloads to AWS

Identity and access management (IAM) is a key component of AWS security.  IAM allows the creation of users, groups and roles. IAM services and features you will most likely consider when host Oracle on AWS are:

1. Security Token Service (STS) : STS generates temporary credentials for an IAM User or for users that you authenticate (federated users). Useful for improving security posture, mobile applications, and identity federation. Here are some basics of STS:
A. Generates a temporary Access Key, Secret Key, and Token
B. Expire automatically (15 minutes ~ 36 hours)
C. You write an “identity broker application” ( sample code here: http://docs.aws.amazon.com/STS/latest/UsingSTS/STSSampleApps.html)
D. Users authenticate to your identity broker
E. Your identity broker provisions temporary credentials via STS
F. SSO via the management console: Temporary credentials can be used to sign user directly into the AWS Management Console


  Get the temporary temporary token (access key ID, secret Key, and security token) by issuing the get_federation_token API call.  The thing to keep in mind with your identity broker application is that you will have to have all the policies defined some where (in code as below, relational database, XML file, JSON templates, some file, etc) as you probably don't want to hard code in the application and will have 1000's of different users with different policies. 
http://docs.aws.amazon.com/AWSSDKforPHP/latest/index.html#m=AmazonSTS/get_federation_token
The role needs to have a policy associated. Here is the way it is done it code:



// Generate a new IAM policy (https://awspolicygen.s3.amazonaws.com/policygen.html)
$policy new CFPolicy($tokenarray(
    'Statement' => array(
        array(
            'Sid' => 'SID' . time(),
            'Action' => array('s3:GetObject''s3:GetObjectVersion''s3:ListBucket''s3:ListBucketVersions'),
            'Effect' => 'Allow',
            'Resource' => 'arn:aws:s3:::my-bucket/*'
        )
    )
));

Here is a REST web services call to generate temporary credentials: http://docs.aws.amazon.com/STS/latest/UsingSTS/CreatingFedTokens.htm

or you can use the assume-role API or web services all in document above. Here you would not need to send in a policy as the role would have a policy:

2. IAM resource level permissions - More information can be found here:  http://aws.amazon.com/about-aws/whats-new/2013/07/08/announcing-resource-permissions-for-amazon-ec2-and-amazon-rds/

3. IAM Roles: Roles can be used to securely allow EC2 instances access other AWS services, enables identity federation with STS, cross account access, and web identity federation. 


A. Allow your applications (e.g., Java) running on EC2 to securely access other services (e.g., S3, SQS, etc)
B. Identity federation (including STS)
C. Web Identity federation : Web Identity Federation allows authenticating via Login with Amazon, Facebook, or Google, getting temporary security credentials, and then using those credentials to make a request to AWS
D. Allow cross-account management/access
Jane in Account A may assume a Role in Account B, giving Jane an Access Key/Secret Key/Token that may be used to make API calls to Account B. 


Wednesday, December 4, 2013

Oracle credentials encrypted and protected in S3

Having worked with Oracle Databases for a very long time, this blog post really caught my interest.   This is great way to insure Oracle credentials are not in scripts, environment variables, programs or other places where they can be read by the naked eye.

This blog post describes how DB credentials could be stored encrypted in S3. The role (IAM role) on the EC2 instance would be used with its short-term security credentials to let the client pull the DB credentials from S3 as needed.

http://blogs.aws.amazon.com/security/post/Tx610S2MLVZWEA/Using-IAM-roles-to-distribute-non-AWS-credentials-to-your-EC2-instances

Tuesday, May 7, 2013

AWS SSO integration with AWS


This is a question that comes up quite often, "How can I delegate authentication into my on premise MS AD for AWS users?"  This product has just been released.
SSO integration with AWS

They were also showcased in Andy’s keynote on Tuesday at the SF AWS Summit.

Wednesday, May 1, 2013

AWS getting started with groups and users

A common question is when first setting up and AWS environment is how to prevent developers, OS administrators, DBAs, architectures and all the different roles you may have in your organization from having the correct privileges.  You use IAM group and users.  You would create a developer group.  Ignore roles to start with as these are for AWS services to access other services  (example: EC2 accessing S3) and cross account access.  Then add policies to the group (use policy generator or select a template). Then add each developer as individual users and adding them to the developer group.

Good resource for all of your questions….You can explicitly manage roles and policy
http://docs.aws.amazon.com/IAM/latest/UserGuide/cross-acct-access-walkthrough-creategroup.html

Nice blog entry here:
https://forums.aws.amazon.com/message.jspa?messageID=197920