Puppetcamp East, Windows Without GPOs, John Rogers, SwissRe
•Download as PPTX, PDF•
0 likes•281 views
This document summarizes a presentation on Puppet Camp 2020 and managing Windows servers without GPOs. It discusses the current environment using Puppet Open Source v6.2 and Puppet Agent 6.11.1 to manage Windows 2008 R2 through 2019 and Linux servers. It outlines the challenges faced in moving from traditional Windows management to Puppet, including steep learning curves and lack of Windows modules. Key steps taken included rolling out Puppet agents, developing GPO and local security policy modules, and using Chocolatey/ProGet for software management.
Recommended
More Related Content
What's hot
What's hot (20)
Similar to Puppetcamp East, Windows Without GPOs, John Rogers, SwissRe
Similar to Puppetcamp East, Windows Without GPOs, John Rogers, SwissRe (20)
More from Puppet
More from Puppet (20)
Recently uploaded
Recently uploaded (20)
Puppetcamp East, Windows Without GPOs, John Rogers, SwissRe
- 1. Puppet Camp 2020 Windows without GPOs John Rogers, March 2020
- 2. John Rogers | March 2020 Who are we The Swiss Re Group is one of the world's leading providers of reinsurance, insurance and other forms of insurance- based risk transfer, working to make the world more resilient. The aim of the Swiss Re Group is to enable society to thrive and progress, creating new opportunities and solutions for its clients. www.swissre.com 2John Rogers | March 2020
- 3. John Rogers | March 2020 Our Current Environment • 2 separate puppet universes, one for puppet code development and one for production • 1 PuppetDB, 1 PuppetCA, 4 Puppet Masters, 1 CMDB • Puppet Open Source v6.2 • Puppet Agent 6.11.1 • Windows 2008 R2 – Windows 2019 • Ubuntu, RedHat, SLES 3John Rogers | March 2020
- 4. John Rogers | March 2020 4
- 5. John Rogers | March 2020 Cool Factoids • Customer managed git repos. Customers can write their own puppet code • Control repo for public modules. Customer can see what is available without needing access to our git repo • End to End automation. Cloud Portal -> Microservice -> CMDB -> Server Provisioning -> Puppet Run 5John Rogers | March 2020
- 6. John Rogers | March 2020 Windows Before Puppet • Traditional: Microsoft OS, Microsoft Tools • GPOs. Always a trade-off between security and flexibility • SCCM for software deployment • SCOM for monitoring • No centralized logging • No self service • Put in a ticket 6John Rogers | March 2020
- 7. John Rogers | March 2020 The Vision • Automation • Infrastructure as Code • Services/API • Self-Service • DevOps • Hybrid Cloud • Security 7John Rogers | March 2020
- 8. John Rogers | March 2020 Why Puppet • The Unix Team was already using puppet • Existing Infrastructure • Existing code and change management processes • one configuration management tools was preferable to two or more • Puppet is highly flexible and extensible 8John Rogers | March 2020
- 9. John Rogers | March 2020 The Challenges • Culture • Steep Learning Curve (Puppet DL, Ruby, Scripting, GIT) • Puppet isn’t Windows (why choose a non Microsoft tool) • Microsoft is Microsoft (why choose a non Microsoft tool) • Lack of modules • Performance (DSC no instantiation, powershell processes) 9John Rogers | March 2020
- 10. John Rogers | March 2020 The How • Rollout of puppet agents on all Windows Servers • Green field approach for Windows 2016 • Holistic approach • GPO Module • Local Security Policy Module • Chocolatey/Proget • PackerIO 10John Rogers | March 2020
- 11. John Rogers | March 2020 GPO Module 11 Preparation • Parse ADMX files into JSON lookup table • Use the CIS policy files to get default CIS settings for the OS • Parse the registry.pol file from the CIS standard to generate the manifest files Agent Run • Provider instantiates current registry.pol files • Provider performs normal create/update/destroy processes and updates hash in memory • Provider writes registry.pol file and runs lgpo.exe to appy settings
- 12. John Rogers | March 2020 12
- 13. John Rogers | March 2020 13
- 14. John Rogers | March 2020 14
- 15. John Rogers | March 2020 15
- 16. John Rogers | March 2020 Local Security Policy Module 16 • The module was written to originally help us to manage the User Rights Assignments for Windows • 3 providers and 4 types • Custom define to search hiera to combine default settings with required settings for role, host, etc • Expanded to include the rest of the secedit.exe functionality • Used the concat module as a basis for the so_privilegerights_fragment functionality so profiles can inject user right assignments into the catalog • https://github.com/johnrogers00/securityoptions
- 17. John Rogers | March 2020 17
- 18. John Rogers | March 2020 Chocolatey/ProGet 18 • Along with PowerShell package manager using ProGet to provide Software Feeds • Now packages can be installed manually or through puppet
- 19. John Rogers | March 2020 19
- 20. John Rogers | March 2020 PackerIO 20 • Using PackerIO to build multiple images for on premise and private cloud infrastructure • Puppet role for packer. – All settings that can be done without a domain are set – pluginsync runs for the first time – initial patching of server – speeds up deployment time of newly provisioned server
- 21. John Rogers | March 2020 The Future • Automated IT Exceptions • Rewrite Modules (Module Hiera) • Utilize Powershell Lib • multiversion(build) support 21John Rogers | March 2020
- 22. John Rogers | March 2020 Special Thanks 22 Raffaela Wüst raffaela.wuest@copebit.ch Andreas Zuber zuber@puzzle.ch Raphaël Pinson raphael.pinson@camptocamp.com
- 23. John Rogers | March 2020 • acl • auditpol • chocolatey • iis • reboot • registry • scheduled_task • telegraf • transition • windows_env • Windows_firewall • windows_smb • swissre/windowsupdate • swissre/gpo • swissre/securityoptions • swissre/windowsnetwork • swissre/service_acl • swissre/srdiskutility • swissre/srlanguage • swissre/meltdownspectre Modules we use for Windows 23
- 24. John Rogers | March 2020 24 Legal notice ©2019 Swiss Re. All rights reserved. You may use this presentation for private or internal purposes but note that any copyright or other proprietary notices must not be removed. You are not permitted to create any modifications or derivative works of this presentation, or to use it for commercial or other public purposes, without the prior written permission of Swiss Re. The information and opinions contained in the presentation are provided as at the date of the presentation and may change. Although the information used was taken from reliable sources, Swiss Re does not accept any responsibility for its accuracy or comprehensiveness or its updating. All liability for the accuracy and completeness of the information or for any damage or loss resulting from its use is expressly excluded.
Editor's Notes
- Notes Puppetmasters are configured to pull commits from customer repos based on tags. So customers/teams developing their own puppet code can tag their work and use this as a deployment mechanism to the puppet servers. This allows them to control how they deploy their changes through DEV, TEST and PROD and provides them with a a way to test and make changes without having to go through our team. Setup a control repo managed via r10k, that allows us to share all of the public respositories with customers so they can see what modules and versions are available for them to use. As opposed to when we had everything inside a single repo that was private and not accessible to others We drive the configuration of services almost entirely through the use of roles and profiles. So when a machine is provisioned via one of the portals, a role is chosen. Either the default none role, which contains the base configuration for the OS, or an application specific role. This entry is written to the CMDB, so that when the puppet agent runs for the first time on the new server, it knows what its role it, and the proper manifests are loaded.
- Notes Not to spend too much on the past, but our existing setup prior to introducing Windows 2016 and Puppet was pretty typical for a Windows environment. We used a lot of Microsoft based tools, tools that are typically centrally managed. Lots of manual processes and for any changes customer had to put it tickets for Windows Operations to perform tasks.
- Around 2015 the business was changing and this forced new requirements on IT. We needed to be more agile and more dynamic to support a changing business A large emphasis on automation to help streamline processes and remove time consuming manual processes Services should be defined, wrapped in APIs to make them consummable by other services. A move toward self service. Frameworks should be in place that allow customers to use IT services without needing tickets Introduction of a private cloud. Introduction of the word cloud changes peoples excpectations. They want things faster, and working out of the box The concept that Security is everyones job. Security cannot be an afterthought, cannot be delegated to another team.
- As with any company, changing the culture is not easy. Struggles with why, why should I change, why change that, etc, etc. Moving the mentality from this is how I manage 1 server to this is how I manage 5000 servers. Unfortunately the learning curve is quite steep. it is not just a matter of learning the Puppet language, but the entire toolset that goes along with becoming a software developer and working more often than not on a unix based operating system. To compound this choosing a non-Windows solution to manage Windows was met with skepticism. The Unix team was already using this tool, and after some successful testing, we decided that having a common toolset was valuable. Being able to reuse the same infrastructure, the same processes, so we could focus on content. In the Windows world, you do things the Microsoft way. Choosing a different approach usually leads to frustration and finding information or experts is typically difficult or impossible. When starting with Puppet on Windows, there was not a lot of modules available, or the ones that were available sometimes lacked features or had to be patched. One of the first realizations that we had was that maybe no one was managing the entirety of windows with puppet. There were modules for networking, modules for IIS, modules for Sharepoint, but the main usage seemed to be just making registry changes with the registry resources type When starting with Puppet 3.8, we attempted to supplement the puppet native modules with the DSC resources, but we quickly moved away from this solution. Making a powershell call for every resource was out of the question and DSC does not support instantiation and managing hundreds and more than a 1000 resources this way was not practical.
- For the entries in the Local Policies, we use this custom module to manage the settings. A few of the settings are set at the domain level via GPO, and we do not manage these settings with puppet for the Advanced Audit Policy Configuration, we are using the auditpol module, though it is in need of updating, but works great For the security options and user rights assignments, camp to camp helped us wrote a custom module to handle our needs The issue was, using a Role/Profile concept there was not really a way to inject user rights into the configuration of a server. For instance, installing SQL onto a server is performed as part of a profile, not a role. The installation of SQL requires certain rights for the technical users who are running as services, so there was no good way to set these at a role level. The implementor of the role would need to know all of the internals of the profiles to understand which hiera variables to set.