FIPS compliance

[jszwedko]

A couple of users in discord have asked about FIPS compliance with regards to Vector:

• https://discord.com/channels/742820443487993987/746076283074773150/867921107875926048
• https://discord.com/channels/742820443487993987/746076283074773150/801807173486116885

I'm not entirely sure what all would be involved to have Vector be FIPS compliant, but at the least it seems like it'd be compiling using this openssl module: https://www.openssl.org/docs/fips.html (probably optionally)

This appears to be required for running applications in AWS GovCloud.

[Datawiz0]

@jszwedko AFIK Vector is FIPS compliant if running on a FIPS compliant environment, For instance Openshift 4.9 is FIPS compliant and have introduced Vector as alternative to Fluentd and I beleive they are still claiming FIPS complaince ;)

[jcantrill]

@jszwedko AFIK Vector is FIPS compliant if running on a FIPS compliant environment, For instance Openshift 4.9 is FIPS compliant and have introduced Vector as alternative to Fluentd and I beleive they are still claiming FIPS complaince ;)

I'm the lead of our logging team looking to introduce Vector as an alternate collector in OpenShift Logging 5.5 (~OCP 4.10) as a tech preview. I would be interested in understanding who "they" in this reference; our team has a release pending in days and I know of no other. We are only able to claim FIPS compliance if we are utilizing openSSL that ships with RHEL/CoreOS but otherwise I don't believe we make any explicit statement

Is there any work planned to address this issue? Is there a place where we can assist to make these changes?

[jszwedko]

Hi @jcantrill !

Thanks for the notes. We have this on our backlog but it hasn't been scheduled yet. I think we first just need to identify what needs to be done to make Vector FIPS compliant.

[syedriko]

Hi @jszwedko! Making Vector FIPS compliant would involve using exclusively a FIPS-audited crypto implementation for all crypto needs. On RHEL/CoreOS that's OpenSSL, supplied by the OS, linked to Vector dynamically. ring has not been FIPS-auditied. It appears the most interesting part of this work is going to be not with Vector itself, but with it's (transitive) dependencies. For example, the AWS Rust SDK depends on ring directly. rustls is having a discussion along these lines rustls/rustls#521.
Just for an idea what else depends on ring (that's for the feature set we at OpenShift care about):

$ cargo tree -i ring --no-default-features --features ocp-logging
ring v0.16.20
├── aws-config v0.9.0
│   └── vector v0.21.0 
├── aws-sigv4 v0.9.0
│   ├── aws-sig-auth v0.9.0
│   │   ├── aws-sdk-cloudwatchlogs v0.9.0
│   │   │   └── vector v0.21.0 
│   │   ├── aws-sdk-sso v0.9.0
│   │   │   └── aws-config v0.9.0 (*)
│   │   └── aws-sdk-sts v0.9.0
│   │       └── aws-config v0.9.0 (*)
│   └── vector v0.21.0 
├── azure_storage v0.1.0 (https://github.com/Azure/azure-sdk-for-rust.git?rev=3ca5610b959b3b6b77bb88da09f0764b605b01bc#3ca5610b)
│   └── azure_storage_blobs v0.1.0 (https://github.com/Azure/azure-sdk-for-rust.git?rev=3ca5610b959b3b6b77bb88da09f0764b605b01bc#3ca5610b)
│       [dev-dependencies]
│       └── vector v0.21.0 
│   [dev-dependencies]
│   └── vector v0.21.0 
├── rustls v0.19.1
│   ├── bollard v0.11.1
│   │   └── vector v0.21.0 
│   ├── hyper-rustls v0.22.1
│   │   ├── aws-smithy-client v0.39.0
│   │   │   ├── aws-config v0.9.0 (*)
│   │   │   ├── aws-sdk-cloudwatchlogs v0.9.0 (*)
│   │   │   ├── aws-sdk-sso v0.9.0 (*)
│   │   │   ├── aws-sdk-sts v0.9.0 (*)
│   │   │   ├── aws-types v0.9.0
│   │   │   │   ├── aws-config v0.9.0 (*)
│   │   │   │   ├── aws-endpoint v0.9.0
│   │   │   │   │   ├── aws-sdk-cloudwatchlogs v0.9.0 (*)
│   │   │   │   │   ├── aws-sdk-sso v0.9.0 (*)
│   │   │   │   │   └── aws-sdk-sts v0.9.0 (*)
│   │   │   │   ├── aws-http v0.9.0
│   │   │   │   │   ├── aws-config v0.9.0 (*)
│   │   │   │   │   ├── aws-sdk-cloudwatchlogs v0.9.0 (*)
│   │   │   │   │   ├── aws-sdk-sso v0.9.0 (*)
│   │   │   │   │   └── aws-sdk-sts v0.9.0 (*)
│   │   │   │   ├── aws-sdk-cloudwatchlogs v0.9.0 (*)
│   │   │   │   ├── aws-sdk-sso v0.9.0 (*)
│   │   │   │   ├── aws-sdk-sts v0.9.0 (*)
│   │   │   │   ├── aws-sig-auth v0.9.0 (*)
│   │   │   │   └── vector v0.21.0 
│   │   │   └── vector v0.21.0 
│   │   └── bollard v0.11.1 (*)
│   ├── rustls-native-certs v0.5.0
│   │   ├── bollard v0.11.1 (*)
│   │   └── hyper-rustls v0.22.1 (*)
│   └── tokio-rustls v0.22.0
│       └── hyper-rustls v0.22.1 (*)
├── sct v0.6.1
│   ├── ct-logs v0.8.0
│   │   ├── bollard v0.11.1 (*)
│   │   └── hyper-rustls v0.22.1 (*)
│   └── rustls v0.19.1 (*)
└── webpki v0.21.4
    ├── hyper-rustls v0.22.1 (*)
    ├── rustls v0.19.1 (*)
    ├── tokio-rustls v0.22.0 (*)
    └── webpki-roots v0.21.1
        └── bollard v0.11.1 (*)

[syedriko]

For the sake of cross-referencing, here is the AWS Rust SDK issue and PR on making OpenSSL the exclusive crypto provider:
smithy-lang/smithy-rs#1529
smithy-lang/smithy-rs#1530

[jszwedko]

Notably we added VRL encryption/decryption functions using pure Rust implementations which will likely be impacted by this initiative.

[pront]

There was some progress on this but also quite a bit of friction:

• chore(deps): bump async-nats to v0.37 #21504 (comment)
• Go required for Rust builds aws/aws-lc-rs#661
• Go required for FIPS build. aws/aws-lc#2129

Fortunately, there's no hard blocker. Someone can resurrect PR #21504