How to know if container configuration data should be trusted

Question

My application (or microservice, etc.) running in a container is reading configuration data. How can I know if the data should be trusted?

Answer

Fortify views all data that comes from outside the application code as a potential vector for an attack, including data from the container’s (ephemeral) file system and persistent data in volumes.[1] Fortify marks all data coming into an application as potentially tainted and requires the data to be validated before it is used.

Best practice is to not trust configuration data. Vulnerabilities in the operating system, the container itself, other applications or services running in the container, and misconfiguration can all lead to compromise of any data kept in the container, persistent data in volumes, etc. Recommendations therefore include:

  • All data should be validated close to where it is used, including data that is read from the container itself. This best practice helps ensure all data is validated and that it is validated correctly for how it will be used.
  • Alternatively, for data coming from the container’s file system, integrity checks can be implemented to verify that the configuration of the container has not been modified by an unauthorized party.

[1] Potential vectors for attack also include for example configuration data read from Kubernetes ConfigMaps and for example Redis in-memory key/value stores.

Additional Guidance

OIS Software Assurance recognizes that the above is not always feasible for all applications. To alternately show that configuration data used by an application running in a container can be trusted the following criteria must be met:

  • Requirement: The developer will need to provide documentation[2] that attests that:
    • The container hosting the application was instantiated using authorized[3] infrastructure configuration files, DevSecOps tool configuration scripts, and/or application run-time configuration scripts to ensure that the container data in question is protected from unauthorized access, and
    • Required system security monitoring and system configuration monitoring is being performed to ensure that configuration data used by an application running in a container is protected from unauthorized access.
  • Requirement: Any sensitive data such as passwords or keys should be encrypted and managed using for example Kubernetes secrets functionality[4] [5]
    • Sensitive data should not be in source code repositories, plaintext files (or in unencrypted volumes, or in runtime variables, or in in-memory key/value stores).
    • If they are not encrypted the developer will need to provide documentation that attests that the sensitive data is being handled securely according to VA policy.

[2] There are no specific presentation or content requirements for the above attestation documentation, aside from addressing the specific technical concerns.

[3] The VA office or organizational entity that provided the authorization must be identified in the attestation.

[4] This particular notional example’s functionality may not be sufficient based on project or ATO needs.

[5] The specific solution used for secrets management must be identified in the attestation or in a readme file.