Being a software engineer and architect I often think of ways to simplify and/or compartmentalize the development efforts of projects/products I work on. This is one of my favorite and most endearing aspects of Symfony that has led me so often to using it for custom application development. (It doesn’t hurt that the recent release of PHP7 has been so fundamentally well regarded for its dramatic performance improvements).
I’ve written about this approach before in an article “Planning Your Tech Stack,” but this in particular goes into more depth and a particular example use-case using Symfony.
One of the great “things” about Symfony is the concept of a Bundle or Component which can be reused on demand across any application thanks to Composer.
Take for example the setup below.
Here we’ve architected a
CoreBundle with components we want to reuse across more than one application. The most obvious being the Entity classes and database handling, so each application shares the same source data. This example application is a basic API with an Admin Module; pretty typical setup for what I help clients with every day.
In this situation, the Api and Admin module want to work with the same data, but have separate authentication mechanisms, so
AdminBundle each have their own
Security component that depends on the underlying
CoreBundle. The API would most likely use JWT or Basic (use JWT, you’ll thank me later) authentication, whereas the Admin module we generally recommend HTTP Auth with a traditional username and password.
Other components are shared in similar ways, but ultimately the point is that in a DRY situation you want to avoid repeating yourself, or your code. And furthermore, with each additional app or service that reuses the component, the model validates itself even further.
I have the great pleasure of participating in a 3 day course Architecting on AWS and wanted to share a high level understanding as a way to both share the basics for anyone “on the fence” for jumping to AWS or not, and also selfishly to help me understand and remember more clearly as I go through the course.
These are my notes from the first of three days:
- NASA is planning to move ~80% of their architecture to AWS
- AWS is a “deny-all” by default security architecture
- Amazon leaves 100% responsibility of application layer to the “owner”
- Intrusion detection and security “not their problem”
- Determining “good” and “bad” traffic is up to the application
- Spot Pricing can be up to 90% discount off standard pricing
- Great real-time status report on AWS services: http://status.aws.amazon.com/
- AMIs are created by region; an AMI available in US-WEST-2 will not be available in US-EAST-1 by default (for example).
- More than 50 Edge Locations sitting outside of designated AZs.
- CloudFront and Route 53 predominantly
- Globally present, separate from regions
- Great for caching
- AWS is completely API driven
- Amazon.com was mandated (by CEO Jeff Bezos) that all development was done via APIs
- Identity Access Management (IAM)
- Create and manage identities
- Not appropriate for application authentication/authorization
- Federated users (permissions for users outside of AWS)
- Multi-factor authentication (MFA)
- Available for individual IAM users, and/or AWS account
- Do not use master account (root) ever
- IAM Roles
- Allow delegation of access to users or services that don’t have static AWS credentials
- IAM users or AWS services can assume roles (temporarily) to make AWS API calls
- AWS re:Invent (~November annually)
- Interesting anecdote: You could theoretically delete your entire “data center” when using AWS.
- Interacting with AWS
- Management Console via credentials
- AWS Command Line Interface (cli)
- Software Development Kids (SDKs)
- Query APIs
- IAM Policies
- JSON format, deny by default, most restrictive policy wins
- If something is explicitly denied, it can never be allowed
- Evaluation logic: explicit deny/allow, implicit deny
- Role based Access Management
- Assign permissions to logical and functional groups
- bulk permissions management (scalable)
- Easy to change permissions as individuals change teams
- IAM Best Practices
- Remove all access/secret keys from root account
- Create individual IAM accounts with Admin privileges mapped to actual persons
- Use groups to assign permissions to IAM users
- Grant least privilege
- AWS Security Token Service (STS)
- lightweight web service that allows creation of temporary, limited-privilege credentials
- Federated users
- authenticate users to your own identity store
- write an “identity broker app”
- users authenticate to the broker
- identity broker provisions temporary credentials via STS
- SSO: temporary credentials can be used to sign user directly into AWS Management Console
- AWS Directory Service
- Managed Service:
- connect aws resources with an existing on premises Microsoft Active Directory
- set up a new standalone directory in the AWS cloud (simple ad)
- AWS Directory Service allow use of existing corporate credentials:
- accessing aws services (workspaces, workdocs)
- accessing aws management console through IAM roles
- Web Identity Federation
- STS API
- temporary credentials to access AWS resources
- Supported web identity providers
- Mobile app can be developed without server-side code and without distributing long-term credentials with the mobile app