anchor.diff:  . Named after the application (as defined by `spring.application.name`)
   . Matching some labels
   
  -Note that, by default, consuming Secrets through the API (points 2 and 3 above) *is not enabled* for security reasons.
  +*Note:*
  +
  +By default, consuming Secrets through the API (points 2 and 3 above) *is not enabled* for security reasons. The permission 'list' on secrets allows clients to inspect secrets values in the specified namespace.
   Further, we recommend that containers share secrets through mounted volumes.
  -If you enable consuming Secrets through the API, we recommend that you limit access to Secrets by using an
  -[authorization policy, such as RBAC](https://kubernetes.io/docs/concepts/configuration/secret/#best-practices).
  +
  +If you enable consuming Secrets through the API, we recommend that you limit access to Secrets by using an authorization policy, such as RBAC.
  +For more information about risks and best practices when consuming Secrets through the API refer to https://kubernetes.io/docs/concepts/configuration/secret/#best-practices[this doc].
   
   If the secrets are found, their data is made available to the application.
   
  
positive.code: 
  Some Spring Cloud components use the `DiscoveryClient` in order to obtain information about the local service instance. For
  this to work, you need to align the Kubernetes service name with the `spring.application.name` property.
  
  Spring Cloud Kubernetes can also watch the Kubernetes service catalog for changes and update the
  `DiscoveryClient` implementation accordingly.  In order to enable this functionality you need to add
  
negative.code: |===
  
  Notes:
  
  * The `spring.cloud.kubernetes.secrets.labels` property behaves as defined by
  https://github.com/spring-projects/spring-boot/wiki/Spring-Boot-Configuration-Binding#map-based-binding[Map-based binding].
  * The `spring.cloud.kubernetes.secrets.paths` property behaves as defined by
  