1. ConfigMap
   1. ConfigMaps bind configuration files, command-line arguments, environment variables, port numbers, and other configuration artifacts to a Pods' containers and system components at runtime
   2. ConfigMaps enable users to separate configurations from Pods and components, which helps keep workloads portable
   3. ConfigMaps makes configurations easier to change and manage, and prevents hardcoding configuration data to Pod specifications
   4. ConfigMaps are useful for storing and sharing non-sensitive, unencrypted configuration information
   5. To use sensitive information in clusters, use Secrets
2. Secret
   1. Secrets are secure objects which store sensitive data, such as passwords, OAuth tokens, and SSH keys, in clusters
   2. Storing sensitive data in Secrets is more secure than plaintext ConfigMaps or in Pod specifications
   3. Using Secrets gives control over how sensitive data is used, and reduces the risk of exposing the data to unauthorized users
   4. Secrets can be encrypted at the application layer using a key managed in Cloud KMS
   5. Generic secrets are created from a local file, directory, or literal value
   6. Docker-registry secret is used to authenticate against Docker registries
   7. TLS secrets are created from a given public/private key pair. The public/private key pair must exist beforehand, and the public key certificate must be .PEM encoded and match the given private key
   8. Most Secrets use the generic type
   9. Data can be a path to a directory containing one or more configuration files or a key-value pairs
   10. Password and user are base64 encoded
   11. Base64 encoding makes information digestible by apps and services that can't handle certain characters
   12. Base64 encoding does not provide security
   13. To use a Secret with workloads, an environment variable needs to be specified that references the Secret's values, or a volume containing the Secret is mounted