13 Security and secrets management

 

This chapter covers

  • Securing state and log files
  • Managing static and dynamic secrets
  • Enforcing “policy as code” with Sentinel

On July 25, 2019, the Democratic Senatorial Campaign Committee (DSCC) was discovered to have exposed over 6.2 million email addresses. It was one of the largest data breaches of all time. The vast majority of exposed email addresses belonged to average Americans, although thousands of university, government, and military personnel’s emails were leaked as well. The root cause of the incident was a publicly accessible S3 bucket. Anyone with an Amazon Web Services (AWS) account could access the emails stored in a spreadsheet named EmailExcludeClinton.csv. At the time of the discovery, the data had been exposed for at least nine years, based on the last-modified date of 2010.

This homily should serve as a warning to those who fail to take information security seriously. Data breaches are enormously detrimental, not only to the public but to corporations as well. Loss of brand reputation, loss of revenue, and government-imposed fines are just some of the potential consequences. Vigilance is required because all it takes for a data breach to occur is a slight oversight, such as an improperly configured S3 bucket that hasn’t been used for years.

13.1 Securing Terraform state

13.1.1 Removing unnecessary secrets from Terraform state

13.1.2 Least-privileged access control

13.1.3 Encryption at rest

13.2 Securing logs

13.2.1 What sensitive information?

13.2.2 Dangers of local-exec provisioners

13.2.3 Dangers of external data sources

13.2.4 Dangers of the HTTP provider

13.2.5 Restricting access to logs

13.3 Managing static secrets

13.3.1 Environment variables

13.3.2 Terraform variables

13.3.3 Redirecting sensitive Terraform variables

13.4 Using dynamic secrets

13.6 Final words