FedRAMP is a certification process by the U.S. government for evaluating the security and compliance of Software as a Service (SaaS) products offered to federal agencies.
FedRAMP certification ensures that SaaS products used by the U.S. government are secure. It’s a standardized approach to security endorsed by the General Services Administration (GSA) and follows a set of security rules (NIST SP-800-53) to check everything from the software's infrastructure to its applications. These rules are the required standards for internal government IT services, and the FedRAMP process is designed to ensure that SaaS offerings hosted on non-government systems meet those same requirements. This approach helps keep government data safe, no matter where it's stored or processed.
FedRAMP streamlines the process of selling to the Federal Government; once a SaaS product is authorized, it does not need to be separately authorized/approved for every government agency that wishes to buy it.
This is a benefit to the SaaS company (opening up the entire government market as a potential customer base) and to the government—shortening acquisition timelines for needed services and, hopefully, providing a more competitive marketplace of pre-approved vendors from which to choose.
Achieving FedRAMP compliant status is possible through an independent assessment by the Joint Authorization Board (JAB) or via agency sponsorship, involving collaboration with federal agencies such as the Department of Defense (DoD) and the Department of Homeland Security (DHS)."
Agency sponsorship is often a good route to take — in addition to completing the authorization process, the cloud service provider gets the benefit of an internal government partner who can provide feedback on the value of their product for government use, helping to steer development in a customer-centric and agile way.
The list of actual security controls for adhering to these requirements is in the thousands, so this post will stay at a higher level. The best strategy for achieving compliance is to design your system with an “inheritance” model for security controls: bake as much into the architecture of your underlying infrastructure as you can so that your platform inherits those controls. Then, bake as much into the platform as you can so that your applications inherit those controls. This results in a narrowing pyramid of requirements as you move from the base infrastructure layer toward your user-facing applications.
In this post, we’ll focus on that middle “platform” layer and some of the high-level requirements you’ll need to ensure your Kubernetes platform is FedRAMP ready.
Addresses NIST SP-800-53r5 CA-7, CA-7(3), CA-7(4), CA-7(5), CA-7(6), CM-2, CM-6(2), CM-7(1)
As we’ve mentioned, FedRAMP is essentially designed to ensure that a cloud product or service meets relevant compliance standards. NIST SP-800-53, the authoritative set of requirements for Federal Agencies, is a general purpose standard that is not cloud or Kubernetes specific. However, there are other relevant standards that will be used to assess a Kubernetes platform when going through FedRAMP. These include the Kubernetes CIS benchmarks and the NSA Kubernetes hardening guide.
To be FedRAMP compliant, your cluster must:
Rad Security does both of these things out of the box: assessing your cluster’s current compliance and continuously monitoring its current state for changes.
Addresses NIST SP-800-53r5 RA-5, RA-5(6), SR-4
The most recent revision of NIST SP-800-53 (revision 5) adds a new section of software supply chain security. This has been a growing area of concern for the government since the 2020 Solar Winds attack. Ensuring your Kubernetes cluster is FedRAMP compliant involves:
Rad Security includes/integrates with a cluster admissions controller to enable actions like signature verification for artifacts and checking that artifacts have valid SBOMs attached before granting admission. Additionally, Rad Security can continuously scan the SBOMs of admitted artifacts to identify new vulnerabilities that need to be remediated.
*Note: Though not specifically required in the NIST standard, the government has been telegraphing for several years now that they intend to require Software Bills of Material (SBOMs) for all components deployed to government systems. You may be able to achieve FedRAMP without this, but it’s probably a good idea to get ahead of this requirement. Rad Security can help you enforce, generate, and handle these documents. The SBOM was initially received by the security community with a great deal of enthusiasm. Implementation has been slow, largely because there are not a lot of systems that can make much use out of SBOMs. Rad Security, however, can help you put your SBOMs to work by continuously monitoring the included components for new vulnerability announcements.
Addresses NIST SP-800-53r5 AC-2(7), AC-2(9), AC-2(12), AC-3, AC-3(7), AC-3(11), AC-3(10), AC-3(12), AC-3(14), AC-5, AC-6, AC-6(1), AC-6(2), AC-6(5), AC-6(7), AC-6(8), AC-6(9), AC-6(10), AC-14, AC-17(1)
NIST and the FedRAMP process lay out a variety of access control systems that may be used in a system. The Kubernetes community has largely coalesced around one of those— Role Based Access Control (RBAC)— as the gold standard for authorization within a Kubernetes cluster. The RBAC concept is even baked into the Kubernetes architecture with Role and RoleBindingobjects (and their Cluster equivalents).
Demonstrating FedRAMP compliance requires ensuring that you:
Rad Security can help you achieve this, providing guidance on your implementation of RBAC. Where Rad Security really shines is that our guidance is directly based on real usage data from your cluster. By identifying the difference between what Roles specify may be permitted and what users are actually doing, we perform a continuous audit for you, resulting in Least Privilege guidance tailored to your actual needs.
Addresses NIST SP-800-53r5 AC-2(12), AC-6(9), AC-17(1), AU-2, AU-3, AU-4, AU-4(1), AU-6, AU-6(4), AU-6(5), AU-6(8), AU-9, AU-9(2), AU-9(3), AU-9(4), AU-9(6), AU-11, CA-7, CA-7(3), CA-7(4), CA-7(5), CA-7(6), CM-6(2), IR-5, IR-5(1), RA-5, RA-5(6), SI-4, SI-4(1), SI-4(2), SI-4(4), SI-4(5), SI-4(11), SI-4(12), SI-4(13), SI-4(15), SI-4(17), SI-4(19), SI-4(20), SI-4(24), SI-5, SI-5(1), SI-7(2), SI-7(7)
There is a certain, perhaps not entirely unearned reputation that exists about government requirements being paperwork drills. And indeed, many of the requirements in NIST SP-800-53 are things that will be assessed once during onboarding and only revisited during re-certification. But as any good security professional knows, the task of security is never done. This is explicitly called out in requirements for continuous monitoring capabilities. Included among them, you must:
We’ve mentioned many of these requirements in the context of other topics in this post already, but it bears repeating that this is what Rad Security is designed for. As your “Kubernetes Security Operations Center,” Rad Security ensures your operations are FedRAMP compliant by continuously monitoring your cluster for exactly these things, helping you refine permissions, spot misconfigurations, and detect behavioral anomalies that may warrant additional investigation.
FedRAMP is the US Government accreditation for SaaS providers, ensuring that their service offerings offer a level of security comparable to what is expected of internal government IT systems at the same “Impact Level.” It can be a daunting, complex process to pursue FedRAMP approval, but you don’t need to tackle it alone. Rad Security can help you achieve FedRAMP by providing assessment and insight into your cluster around your adherence to industry and government benchmarks, supply chain security and vulnerability management practices, use of RBAC and the Principle of Least Privilege, and by providing you with continuous monitoring and audit capabilities.