In previous posts, Stack Clash Mitigation in GCC — Background and Stack Clash mitigation in GCC: Why -fstack-check is not the answer, I hopefully showed the basics of how stack clash attacks are structured and why GCC’s existing
-fstack-check mechanism is insufficient for protection.
So, what should we do? Clearly we want something similar to
-fstack-check, but without the fundamental problems. Enter a new option:
The key principles for code generation to prevent a stack clash attack are:
Continue reading “Stack clash mitigation in GCC, Part 3”
I work at Red Hat on GCC, the GNU Compiler Collection. For the next major release of GCC, GCC 10, I’ve been implementing a new
-fanalyzer option: A static analysis pass to identify various problems at compile-time, rather than at runtime.
My thinking here is that it’s best to catch problems as early as possible as the code is written, using the compiler the code is written in as part of the compile-edit-debug cycle, rather than having static analysis as an extra tool “on the side” (perhaps proprietary). Hence, it seems worthwhile to have a static analyzer built into the compiler that can see exactly the same code as the compiler sees—because it is the compiler.
Continue reading “Static analysis in GCC 10”
This article demonstrates the use of multiple vault passwords through vault IDs. You will learn how to use vault IDs to encrypt a file and a string. Once they’re encrypted, the vault ID can be referenced inside a playbook and used within Red Hat Ansible and Red Hat Ansible Tower.
Starting with Ansible 2.4 and above, vault IDs are supported
Vault IDs help you encrypt different files with different passwords to be referenced inside a playbook. Before Ansible 2.4, only one vault password could be used in each Ansible playbook. In effect, every file needed to be encrypted using the same vault password.
To begin with, vault IDs need to be pre-created and referenced inside your
ansible.cfg file. The following excerpt is from
ansible-config list for the configuration
Continue reading “Vault IDs in Red Hat Ansible and Red Hat Ansible Tower”
Red Hat single sign-on (SSO)—or its open source version, Keycloak—is one of the leading products for web SSO capabilities, and is based on popular standards such as Security Assertion Markup Language (SAML) 2.0, OpenID Connect, and OAuth 2.0. One of Red Hat SSO’s strongest features is that we can access Keycloak directly in many ways, whether through a simple HTML login form, or an API call. In the following scenario, we will generate a JWT token and then validate it. Everything will be done using API calls, so Keycloak’s UI is not exposed to the public directly.
In my previous article, I demonstrated the complete implementation for enabling OAuth-based authorization in NGINX with Keycloak, where NGINX acts as a relaying party for the authorization code grant. NGNIX can also act as a reverse proxy server for back-end applications (e.g., Tomcat, Open Liberty, WildFly, etc.), which can be hosted on an enterprise application server.
Continue reading “Role-based access control behind a proxy in an OAuth access delegation”
Keycloak provides the flexibility to export and import configurations easily, using a single view to manage everything. Together, these technologies let you integrate front-end, mobile, and monolithic applications into a microservice architecture. In this article, we discuss the core concepts and features of Keycloak and its application integration mechanisms. You will find links to implementation details near the end.
Continue reading Keycloak: Core concepts of open source identity and access management
In this article, we’ll cover microservice security concepts by using protocols such as OpenID Connect with the support of Red Hat Single Sign-On and 3scale. Working with a microservice-based architecture, user identity, and access control in a distributed, in-depth form must be carefully designed. Here, the integration of these tools will be detailed, step-by-step, in a realistic view.
This article exemplifies the use of tools that can securely run your businesses, avoiding using homemade solutions, and protecting your services by using an API gateway, preventing your applications from being exposed to the public network. The use of an API gateway also provides additional access control, monetization, and analytics.
Continue reading “How to secure microservices with Red Hat Single Sign-On, Fuse, and 3scale”
Security-conscious organizations are accustomed to using digital signatures to validate application content from the Internet. A common example is RPM package signing. Red Hat Enterprise Linux (RHEL) validates signatures of RPM packages by default.
In the container world, a similar paradigm should be adhered to. In fact, all container images from Red Hat have been digitally signed and have been for several years. Many users are not aware of this because early container tooling was not designed to support digital signatures.
In this article, I’ll demonstrate how to configure a container engine to validate signatures of container images from the Red Hat registries for increased security of your containerized applications.
Continue reading “Verifying signatures of Red Hat container images”
As developers increasingly make use of containers, securing them becomes more and more important. Gartner has named container security one of its top 10 concerns for this year in this report, which isn’t surprising given their popularity in producing lightweight and reusable code and lowering app dev costs.
In this article, I’ll look at the three basic steps involved in container security: securing the build environment, securing the underlying container hosts, and securing the actual content that runs inside each container. To be successful at mastering container security means paying attention to all three of these elements.
Continue reading “3 steps toward improving container security”
The Picketlink project is now a deprecated module in Red Hat JBoss Enterprise Application Platform (EAP), so there’s a chance that Picketlink will no longer ship with the next release of EAP/Wildfly and that there will not be any fixes in the near future for the
Picketlink, however, is now merged with Keycloak, an open source identity and access management solution developed by Red Hat’s JBoss Community. In this article, we’ll present an alternative solution to the
picketlink module. Some organizations use
picketlink as the service provider to enable SAML-based authentication with a third-party identity provider (i.e., Active Directory Federated Services (AD FS), OKTA, PingFederate, etc.). In this, article, we’ll see how the keycloak-saml adapter can be configured in the place of Picketlink to enable SAML-based authentication with a third-party identity provider.
Continue reading “Using Keycloak instead of Picketlink for SAML-based authentication”