Skip to main content

Posts

Showing posts from 2019

AWS Sagemaker routing settings

Amazon SageMaker Jupyter notebooks are used to perform advanced data exploration, create training jobs, deploy models to Amazon SageMaker hosting, and test or validate your models. The notebook instance has a variety of networking configurations available to it. In this blog post we’ll outline the different options and discuss a common scenario for customers.

Using the Amazon SageMaker console, these are the three options:
No customer VPC is attached.
Customer VPC is attached with direct internet access.
Customer VPC is attached without direct internet access.

Each of the three options automatically configures the network interfaces on the managed EC2 instance with a set of routing configurations. 

More information here:
https://aws.amazon.com/blogs/machine-learning/understanding-amazon-sagemaker-notebook-instance-networking-configurations-and-advanced-routing-options/

Breaking down AWS IAM terminologies

AWS IAM (Identity and Access Management) in one of the most complex and misunderstood concepts. It's easy to make mistakes while defining proper permissions for resources in the account or cross account. Here are a few basic terminologies from IAM:

IAM users: Used for Human users, such as long term security credentials

IAM roles: Used for applications, automated services, they are short term security credentials. For example, a Lambda function wants to access EC2 instance.

IAM principal: An identity defines within an AWS account

Policies: Policies are permissions- they can be attached to Users, Groups or Roles. AWS authorizes every API call against the IAM policies that apply.

Breaking down IAM Policy (JSON files):

'Effect' clause: Describes if an action is allowed or not by setting 'Allow' or 'Deny'

'Action' clause: What all actions on a particular resource can be performed. A wild card (*) indicates all actions, which is very insecure permissions

AWS Landing Zones

AWS Landing zone: A framework for defining and creating foundations for accounts by automating, baking security baseline, controls, governance, organized, auditable, scalable and self serviceable.

A set of best practices ingested in an AWS account before migration. Reliable infrastructure. The tenet of LZ are:
- Automation driven versioned infrastructure, such as CI/ CD, Cloudformation templates
- Multi-account AWS environment based on AWS best practices, limiting blast radius
- Adaptable foundation with guardrails, safeguarding in case of any mis happening
- Set of architecture patterns, proxy accesses

Building/ Designing LZ components:
- Accounts: as discussed Multi account strategy
- Network:Domains, Direct Connect, Core Services
- Security: Centralized Logging, Configuration, Image (AMI)
- IAM: Access, Identity, Federation
- Cloud Users: Provide users to deploy the accounts, services by using Service Catalog, Automation (avoid manual steps) etc
- Now, Migrate, Iterate the above s…

AWS Security Anti Patterns

The below are a few security anti patterns for AWS cloud which should be avoided when implementing comprehensive cloud security strategy:

Security Anti-patterns Categories:
- Account Structure
- N/w design
- Auditing
- S/W delivery

AntiPattern (Account Structure): Personally owned AWS account
- Make sure the Root account (login, MFA) is not tied to a person's email id. Root email id should be tied to team DL
- Root MFA must be tied with some sort of official hardware device
- Contact info etc must be of office address
- No one logs into the account root. Use IAM only.

Anti-pattern (Account Structure): AWS account overcrowding
- Not all and every services/ teams should be placed under one single account. It becomes very hard to manage policy wise and governance wise
- If admin creds for the account is compromise, the blast radius will be more, all the services get compromised
- If some of the services are in scope for compliance, and since they are not separated, it'll be a co…

IAM Policies in a nutshell

A Policy is 'Deny' by default

Types of Policies:
1. SCP- SCP or Service control polcies. AWS Organizations use this kind of policies.For example, Guardrails to disable service access on the principals in the account.

2. IAM- Permission Policies and Permission Boundaries- Granular permissions on IAM principles (users and roles) and control maximum permissions they can set.

3. AWS STS- Security Token Service- Reduce general shared permissions further

4. Resource based policies: Cross-account access and to control from the resource

5. Endpoint polices- generally attached with VPCs- Control access to the service with a VPC endpoint.


How all these policies work together- within an account:

SCP AND [IAM policies OR Resource based policies]- If both policies match- then the matched action will be allowed, otherwise denied.

How all these policies work together- across accounts:

SCP AND [IAM policies AND Resource based policies]- All the 3 must have the same actions matched- the action will be …

Exploiting meta-data on AWS

Introduction:
Metadata server: Every EC2 instance has some user scripts which can be used to pull configuration to launch that EC2 instance. Those configs are stored on a Metadata server (169.254.169.254) 'private' to that Ec2 instance. Each time an Ec2 instance starts , AWS attached the " meta data server" to it, which can be accessed from the instance itself using http://169.254.168.254. The instance meta-data stores information such as :AMIid, Private IP address, Instance Type etc...and...

User-data: OS boot scripts:
AWS allows you to boot up the EC2 using a custom User-data scripts- such as web application, Apache web server, keys. credentials etc. This script, also called user data, is stored by AWS in the instance metadata and retrieved by the OS during boot.

Instance profile:
When EC2 instance wants to access other services such as S3, it uses credentials to access it. Instance profiles give Ec2 instances a way to access AWS services. AWS creates a unique set of…

AWS IAM in a nutshell

IAM users: Used for Human users, such as long term security credentials

IAM roles: Used for applications, automated services, they are short term security credentials. For example, a Lambda function wants to access EC2 instance.

IAM principal: An identity defines within an AWS account

Policies: Policies are permissions- they can be attached to Users, Groups or Roles. AWS authorizes every API call against the IAM policies that apply.

Breaking down IAM Policy (JSON files):

'Effect' clause: Describes if an action is allowed or not by setting 'Allow' or 'Deny'

'Action' clause: What all actions on a particular resource can be performed. A wild card (*) indicates all actions, which is very insecure permissions

'Resource' clause: Exact resource ARN.

Policies attached to Resources (more granular level IAM policies):

Generally IAM polcicies apply to Principal, but in some scenarios, the policies can be attached to individual resources too, such who can access th…