Showing posts with label temporary. Show all posts
Showing posts with label temporary. 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. 


Saturday, November 30, 2013

AWS S3 temporary access to S3 bucket files

Sharing files using S3 can be easily be done in the S3 buckets permission by adding 'everyone' to the permissions on the buckets and files. However, you probably don't want any person in the world accessing your files. Here are a couple of quick and easy methods.

1. Temporary URL : Use a tool like S3Fox and you can get a pre-signed URL with a time limit.  This limitation with this approach is that if you have a large number of files you need to generate and send a URL for each file.



2. IAM User : The policies you need to use can be found here: http://mikeferrier.com/2011/10/27/granting-access-to-a-single-s3-bucket-using-amazon-iam/

You also need to provide the URL for IAM user sign-in URL for your account, the IAM user, and the IAM user password. Remember, you need to add a password to the user after you create it.


It is then easy to delete this user or change the password to make sure that if this URL, account and password gets into the wrong hands your files are not downloaded.

Friday, June 7, 2013

Oracle Database on ephemeral drives


Using EC2 ephemeral storage (either disk or SSD) is a way to achieve higher IO throughput.
You could use the design pattern Redshift uses (these use the HS1.* instances which have similar storage characteristics to the hi1.4xlarge instances) - "the first line of defense consists of two replicated copies of your data, spread out over up to 24 drives on different nodes within your data warehouse cluster".  This includes:

  1.  All data written to a node in your cluster is automatically replicated to other nodes within the cluster
  2.  All data is continuously backed up to Amazon S3

Oracle on SSD as it is recommendation to get highest level of IO when running Oracle on EC2.