LDAP and DNS Native Support within OPA
LDAP and DNS native support within OPA
The ability to use regular expressions to extract data from LDAP and DNS sources for the purpose of policy compliance aligned particularly with Zero Trust Environments.
Zero Trust Environments
NIST Zero Trust and UK NCSC Zero Trust state the importance of knowing your devices and users is crucial to the securing those systems.
For regulated enterprises and governmental organisations such information resides in
- DNS for devices (A Records), services (CNAMES, MX, SRV), DNSSEC records for the validity for the delegated domain, and SOA and NS records for domain delegation.
- LDAP for users and groups, frequently authenticated via Kerberos or Natively.
There are recommendations of Azure Naming Best Practices and GCP Naming Conventions which further encourage these conventions to propagate from DNS Names to Roles which may be implemented in group names which resided in the LDAP repositories of the organisation.
Policy example
The ability to confirm that a DNS Server is using dnssec, and that it is providing an SRV record to the LDAP server which in turn can be authenticated to and confirm that a hostmaster group exists and it has an LDAP attribute MailEnabled and to discover that it has a valid owner within the organisation or a group is part of validating the conformance to regulatory and best practice standards.
The ability to confirm that a service is published to a DNS A record. that the service name is reflected into group names within the LDAP environment, which have appropriate roles which are present within the service/application and that each of these roles which are reflected within the groups when queried via LDAP have a groupOwner attribute and this owner is either a LDAP group with valid members or an individual which exists within the organisation.
Ideal Solution
Available within the REGO environment the ability to authenticate to DNS and LDAP sources to extract appropriate attributes and values stored within the services and to compare these between one another to confirm policy alignment
Barely Good Enough
Currently it is possible to use the OPA Bundles, and make use of calls to services such as Azure AD
Connect-AzureAD
get-AzureADuser -Top 10 | select UserPrincipalName,userState,mailnickname | Convertto-Json
and to populate the attributes into local files and then run the policy on them. However the pattern matching between stores within the bundles is clunky and complex to match naming conventions without richer regular expression support.
Additional Context
The risk profile of organisations is directly related to the ability to align with regulatory mandates, such as those found in Software Bills of Materials,Zero Trust Principles and Senior Manager Regime
The ability to compare the compliance regime in a standard manner, for example via an OPA policy report, allows simple comparison between competing organisations. If this information was made available to regulators or ratings agencies such as S&P it provides opportunities for the markets to reprice the risks associated with organisations and for new organisations so demonstrate their improved position over time.
If OPA and the REGO language don't take this on, then the likelihood is every organisation will manage this in different ways and the opportunity for comparisons between organisations and real-time reporting to regulators may be lost.
Hi there! 😃 And thanks for raising this. This looks like two disparate feature requests to me (LDAP / DNS), or what do you think? Since there's already an open issue for an LDAP built-in function (and you've commented on that), could you please reduce this issue to describe the capabilities you'd like to see added in OPA around DNS? If there are details missing in the open LDAP issue, let's have them added there.
Since there is an open LDAP issue already, I'll close this for now. Feel free to open a separate issue for what you'd like to see around DNS though!
Changing the closed status, I think the other one is more appropriate for duplicates.