1/3: Assorted Security Topics in Open Cloud: Overview of Advanced Threats, 2015’s Significant Vulnerabilities and Lessons, and Advancements in OpenStack Trusted Computing and Hadoop Encryption by Jason Cohen
Jason works for Intel, so his content was focused on Intel-based solutions. He commenced his talk with a quick summary of recent security vulnerabilities:
- openssh
- keyring exploitation - SELinux protected
- venom:QEMU vulnerability, exploited flaw in virtual floppy controller
- recon
- intrusion
- backdoor
- credential acquisition
- utility installation
- privilege escalation/lateral movement/data exfiltration
- persistence
Defences
- Active Patch management
- cloud technologies
- Separation of roles
- security automation
- user security training and enforcement
- protect the data. Encryption and key management
- physical security
1/4: Managing Infrastructure as Code by Allan Shone
Allan Shone from Manageacloud provided a tour of techniques and tools for managing cloud and bare-metal infrastructure as though it was code. Naturally, manageacloud did quite well in his analysis. He started with a little history.
In the 'past', everything was manual, hostnames were based on function, documentation was fragmented and unmanageable consisting of text files, wikis, spreadsheets, shared drives, proprietary software solutions and shell scripts. The mess was difficult to keep up to date. There were no recent status indicators, interfaces were cumbersome and proprietary. Keeping up to date was a time consuming mess.
I say 'past', because this is frequently the reality I see.
The priorities (according to Allan) are:
Ideas: versioning, easier interface, provision of host state
First: Orchestration
Next: Managing dependencies
Allan then listed the available tools with his pros and cons. The examples were all for AWS leaving me to wonder how well they perform otherwise, particularly since I ditched AWS some time ago.
Basic Provisioners
- ansible: inheritance, variable configuration, easy, YAML, playbooks, agentless.
Drawbacks: difficult to track created instances, supplier specific wrapper, versioning is DIY, basic.
- Chef: based on Ruby, fluent way of pushing out notifications, variable capabilities, cookbooks synchronised with the chef server.
Ddrawbacks: dedicated management server, ruby, plugin infrastructure, OS and package restrictions
- Puppet: simple syntax, server model, automation
Drawbacks: puppet specific language, complex infrastructure, dependency based,
Hosts
CloudFormation: Complete physical IAC, JSON, AWS, automation
drawbacks: AWS, JSON can be difficult to create and maintain with no comments, not idempotent, templates are very large.
Infrastructure pieces:
- software management, host management, resources
- general tool that provides one but not the other
- arbitrary scripts
Combinations
- s/w dep managed
- hosts instatiated or made available on demand
TerraForm: orchestrate and provision, syntax is easy
DB: Tightly integrated with vendor, syntax, delays, newcomer
ManageCloud: complete solution, simple, built in versioning, open vendor, framework approach.
DevOps
- automation is key aspect, hybrid role, interface
Workflows
- focus on processes
- need to be suitable for the tool
- size of infrastructure
Decisions
- situations make decisions difficult
- complete solutions not always necessary
Other tools: CFEngine, Salt, Heat, OneOps
Future: Better ways to share and extend, inheritance, complete control with automation of infrastructure sets, simple.
The afternoon sessions followed, fortunately they were lighter than the previous sessions, giving the brain some time to heal.
1/5: Cloud Anti-Patterns by Casey West
Casey West made a reappearance with a humorous take on going cloud native. He did this by treating resistance to cloud adoption as a mental illness with five stages similar to the stages of depression and listing the "anti-patterns" that oppose adoption. The dual emphasis was on architecture, automation and the delivery pipeline.
Denial
- Containers are just like tiny VMs
- We don't need to automate continuous delivery
Anger
- Works on my machine
- Dev is just #yolo-ing to prod
Bargaining
- We crammed this monolith into a container and called it a microservice
- Bi-Modal IT (Gartner) as an excuse not to change
- Legacy s/w - anything you can't iterate quickly enough
- What if we create microservices that all talk to the same data source.
Depression
- We made 200 microservices and forgot to setup Jenkins
- We have an automated build pipeline but release twice a year
- Work backed up and not released is risk
Acceptace
- All software sucks
- Respect CAP theorem
- Respect Conway's Law
- Small batch size works for re-platforming, too
- Automate everything
Operability is:
1. MicroServices architecture
2. Devops culture
3. Continuous delivery
The last two talks I got very little out of, my brain having mostly shutdown at this point in time.
1/6: Cloud Crafting – Public / Private / Hybrid by Steven Ellis
What I got out of this is to involve people in the automation process - PaaS (People as a Service) with ServiceNow.
The idea is for your monitoring systems to generate detailed service requests rather than waiting for someone to notice the red flag and investigate what's wrong.
1/7: Live Migration of Linux Containers by Tycho Andersen (Canonical)
This talk was about LXC and the promises of LX(C,D) 2.0 not yet released. It looked quite interesting, but by this time I was barely awake.
Tomorrow: The SysAdmin MiniConference.
No comments:
Post a Comment