All OpenStack services can be configured to provide fine-grained access to resources using policies. This can make an installation more secure by only allowing users access to the minimal amount of capabilities they need to effectively consume cloud resources to run their workloads in the cloud. This extends to administrators, who don't always need to have complete access to all services in order to do their jobs. Policy configuration, however, is a complicated task, and if not done correctly, can have the adverse effect of making a cloud less secure. In this session, we'll discuss the user model that's employed by most OpenStack services, and how policies interact with this model. Once you understand this, it will be much easier to figure out how to write policies that acheive your security goals. Because policy changes can have far-reaching (and unintended) effects, we'll discuss the importance of testing a policy configuration and look at some strategies for effective testing.
Though it's been possible since Queens to run many OpenStack services safely without a policy configuration file, the default settings do not meet the needs of all deployers. Configuring custom policies, however, can be difficult (and dangerous). This task can be made easier if an operator understands the user model that the developers writing the code work with, and how policies interact with this model. Understanding of how this all hangs together only goes so far, however, so we'll also discuss effective testing strategies and why they are important. This session will be useful to any security-conscious operator who wants to configure access to services (even administrative access) using the principle of least privilege, so that users (and administrators) have access to what they need to effectively do their jobs, but no more.
Registration Opening Soon
Registration will open for you to purchase passes for the OpenStack Summit very soon!
We're excited to see you there!
