This article positions key features employed by Red Hat CloudForms to secure the wealth of management operations it provides as a Cloud Management Platform (CMP).
CloudForms Providers
Red Hat CloudForms connects to providers, these are management end-points that provide to CloudForms inventory, metrics, event and automation capabilities. Red Hat CloudForms transforms these provider capabilities into business aligned Service Management, Compliance and Optimization.
When connecting to a provider Red Hat CloudForms does so using a set of credentials or token/key access.
Accessing CloudForms Providers
The level of access to a provider is determined by the use cases you wish to fulfill. This infers that the level of access could be restricted to the minimum requirements which is a good security practice.
However the features that CloudForms provides as a Cloud Management Platform to the providers it supports are such that the level of access required is typically way past the threshold of minimum requirements, in fact in practice for Red Hat CloudForms the administrator account is required but not mandated for most providers.
Each provider differs in the capabilities it can provide for automation, metric stored, inventory discovered or events collected. Therefore there is no single solution on the provider side than to configure a custom set of privileges per provider platform, maintain this as new use cases are covered by Red Hat CloudForms. This is a huge undertaking as follows;
Day 1 : The service account is configured with least privilege for the only provider connected to CloudForms. All working OK.
Day 2 : A new use case is to be covered by CloudForms, this would require updating the service account to include any new privileges required to meet the new use-case.
This process has to be repeated every time Red Hat CloudForms is given new use cases to cover in the environment.
Accessing a provider with an account of most privilege is of concern for the following reasons;
Extends the attack surface of the platform to encompass the management platform too.
This is a valid concern. Without the management platform you could state that number of entry points to the provider platform is less. The issue with this argument is that the provider platform itself should be questioned on its ability to granularly apply role based access rules to every operation performed from its tooling. This is where CloudForms adds security value to the provider platform, ensuring compliance and governance is adhered to, a capability not covered by any of the provider endpoints that Red Hat CloudForms integrates with.
The management platform has destructive capabilities that it can perform on a provider platform.
The capability to remove objects from a provider platform or add new ones to it forms a major role in most Cloud Management use cases.
Example – Quarantine virtual machines that are exposed to Heartbleed.
This use case, requires change rights in a provider platform. The use case also addresses a primary security concern.
In both cases one has to balance the need for automation and compliance against that the need of security requirements. This is why when addressing security requirements it’s important to do so knowing that the answer is not always a simple yes or no to compliance. Often there is need to defer a requirement to a dependent secondary service such as authentication, or mitigate the compliance to the requirement through the use of a solution rather than just a single feature.
Secure Operations Management
The balance addressed in this article is to simply give the management platform full rights to the provider platform but in turn secure the management platform to meet the security requirements for connecting to the environment. After all, every environment should have a pattern for onboarding management services as its a base capability for a management platform to connect to an end point.
We discuss the features that CloudForms employs under two headings Deferring or Mitigating.
Deferring
The following features in CloudForms would be considered deferrable. By that we mean secondary services should meet the security requirement.
Red Hat CloudForms supports the following authentication solutions;
IPA/AD Trust Authentication – Active Directory (AD) Trust Authentication in Red Hat CloudForms is supported with External Authentication to IPA.
This provides IPA Users access to the Appliance Administrative UI and the REST API using their AD credentials using the kerberos authentication protocol.
LDAP/LDAPS – This is most common and is native to CloudForms. LDAP/LDAPS allows for access to Microsoft Active and other directories. The groups are fetched and matched in CloudForms, giving pass through access to CloudForms Role Based Access mode and tenant spaces.
Single Sign On – Implemented with Keycloak and using SAML v2.0. The SAML implementation has been tested with KeyCloak but is implemented generically using Apache’s mod_auth_mellon module and should work with other SAML Identity Providers.
The current implementation only secures the Appliance’s Web administrative UI with SAML.
Two Factor Authentication – CloudForms external authentication provides 2-Factor Authentication via IPA. This provides IPA Users access to the Appliance Administrative UI and the REST API using their IPA Password followed by a One-Time-Password.
Apache Web Server
CloudForms uses the Apache web server to present the API and UIs through. SSL encryption is fully supported for all access.
Red Hat Enterprise Linux
Red Hat CloudForms is available as virtual appliance, this has a based operating system of Red Hat Enterprise Linux. Direct access to the operating system is governed as any secure implementation of Red Hat Enterprise Linux.
Firewall
The firewall configuration for CloudForms by default is the minimum viable for full product function.
Security Technical Implementation Guide – (STIG)
CloudForms can be configured to be locked down to be complaint against STIG requirements.
Security Content Automation Protocol – (SCAP)
CloudForms can be configured to be locked down to be complaint against SCAP vulnerabilities.
Mitigating
We mitigate the use of administrator access to a provider platform because CloudForms can secure its user and api entry points against misuse or attack using the following features;
Auto Logout
Users are automatically logged out of Red Hat CloudForms after 5 mins of inactivity. This is configurable.
Role Based Access
CloudForms employs Role Based Access Control. Within CloudForms and an administrator can define new custom roles or use out of the box ones to finely control what areas of the User Interface a role may access and to what level of access such as view, modify, execute or delete.
The following is the role tree that defines the object areas within the CloudForms UI and the level of access.
The example shows the out of the box “Limited Self Service User” role having access to view Templates, VMs and VMs & Template accordions.
Another example could be the out of the box “Container Operator” role, that grants only access to view dashboards and topologies under container providers.
With Role Based Access you can define roles to meet the security requirements of a persona executing the use case. If you wish to allow access to Container Operators then do so using a role template similar to the above. This allows for CloudForms to connect to the container provider platform using administrator rights, but the users accessing the same provider platform though CloudForms are restricted to their use case/persona. No user will perform a duty in the CloudForms UI unless the Role for that User allows them to, this is configured by a CloudForms Administrator as part of implementation of the cloud management platform.
Tenancy
Red Hat CloudForms implements a tenancy model for defining your organisation structure in. This allows for group level access to the resources that are available in the tenant space. No one tenant can access each other’s resources without the rights to do so. Tenancy is configured by a CloudForms Administrator as part of implementation of the cloud management platform.
The default tenant model out of the box is as follows;
The tenant “My Company” is allowed access to all resources that the group list shows in the graphic.
Shown is the tenant “Line of Business”, that has only the “Standard User” group assigned. This group has only access to resources as defined by the CloudForms administrator. The group belongs to a Role as described in the previous section.
Tenants also support child tenants and projects. Either of which inherit from the parent and can have their own group assignments. Tenants, Child Tenants and Projects should meet most organizational structures.
Quota
You will want to protect your provider platforms from over provisioning, CloudForms introduces quota to the provider platforms it supports. Tenants, Projects, Groups or individual Users can be assigned quota limits. Example;
The example shows that the “Line of Business” tenant has 100 Virtual CPUs Allocated. Currently nothing has been provisioned, but as new VMs are provisioned into a provider for users in this tenant the “In Use” will increase;
The graphic now shows that 50 Virtual CPUs have been consumed and 100 Allocated so 50 remain.
Having quota protects the provider platforms from being over provisioned. The provider platform administrators can adjust the quotas in CloudForms to meet the environmental limits or business needs, such as project budget control.
Reporting
CloudForms has extensive reporting capabilities. The reporting engine can access any of the event, inventory, metric or request history stored in the Virtual Machine Database. Reports generated can be automatically emailed to alert users of issues or status of the provider, their virtual machines or CloudForms itself. For example provider platform administrators could ask for a report to be generated that details the users defined in CloudForms and actions performed on a daily basis.
The graphic shows the request history as a sample report that can be saved or emailed. This can alert provider platform administrators to issues with the platform or to user activity.
Dashboards
CloudForms users are presented dashboards of information pertaining to their resources in their tenant space.
The default out of the box dashboards mixes user and operator information in a single view.
You may wish to restrict what users see, such as there is little requirement for a user to view the capacity and utilization of the underlying hypervisor hosts.
The graphic shows a new dashboard with only the “Guest OS Information” and “Vendor and Guest OS Chart”. The result is
Having the ability to mashup dashboard for your business needs is also a security requirement to ensure that the management platform is presenting the right level of information to varying user groups.
Smart State
CloudForms is unique as a Cloud Management Platform in that it can scan the internal file system of virtual machines and instances. The technology is called Smart State and can return Users, Groups, Processes, Packages, Applications, Registry Keys, Files and File Contents. The capability has varying support for both Windows and Linux file systems.
Users and Groups identified can be used to see if virtual machines including CloudForms itself has had its operating system account database adjusted.
This example shows the packages found along with files identified. You can configure CloudForms to scan for certain files and collect their contents back for further conditional processing. Knowing the packages and package versions allows you to identify vulnerabilities or misconfiguration of server roles.
This example shows how the contents of a file can be retrieved by CloudForms. Having the contents available inside CloudForms allows for further reporting of misconfigurations or non-compliance. This feature can be used to identify if CloudForms itself is drifting in configuration from the requirements mandated by the provider platform.
Compliance
CloudForms can check the compliance of any virtual machine or instance.
The example shown is for a virtual machine where a compliance policy has been defined and ran for SELinux enforcement. For the compliance to check this, the previously discussed Smart State technology was used to collect the contents of the selinux.cfg file on the filesystem and conditionally process its contents for the desired setting. CloudForms can have the provider platforms requirements defined as policies within its “Control” capability and applied to itself, alerting non-compliance via email or any other means available to automate or Ansible.
Container Smart State
CloudForms also offers the same compliance as virtual machines against the Smart State detail collected for container images.
The example shows the packages collected and also an additional compliance feature of SCAP results.
The SCAP results show what vulnerabilities exist in container images. This is a value item to the provider platform. Without CloudForms performing this duty, the container provider platform is exposed to running non-compliant container images.
Automate
The Automate area of the product allows for automation to be defined and executed. This area of the product is governed by the Role Based Access system and can be enabled or disabled per role and group. Only CloudForms administrators and Automation Engineers would/should have access to this area.
RESTapi
CloudForms can be accessed over a RESTapi, this is secured using the same authentication subsystem to that of the CloudForms user interfaces. This means that when you authenticate with the RESTapi the visibility and actions you can perform is limited by the role based access model defined for your tenant, project or group space.
Virtual Management Database (VMDB)
CloudForms stores all the requests, metrics, events and inventory information within its VMDB. This means that you can track or trace any action performed by CloudForms, or on the provider by other tooling. You can use CloudForms to audit the provider platform and provide reports to unusual activity or meet regulatory requirements for audit data retention.
CloudForms Log Files
CloudForms stores all user actions for who, from, when and what they did within CloudForms . This means that you can track or trace any action performed by users. The log files can be picked up by any log analysis tool to identify any non compliance or you could define CloudForms policies to do this using Smart State and CloudForms Control.
Summary
“Users logging into CloudForms is NOT the same as CloudForms connecting to a Provider platform with Administrative rights”
This means, just because CloudForms is connected to a provider platform using an admin account does not give the users logging into CloudForms the same rights. It can, but we advise that CloudForms is implemented as a Cloud Management Platform, utilizing its RBAC model and many authentication integration points.
Quelle: CloudForms
Published by