github.com/KyaXTeam/consul@v1.4.5/website/source/docs/connect/security.html.md (about)

     1  ---
     2  layout: "docs"
     3  page_title: "Connect - Security"
     4  sidebar_current: "docs-connect-security"
     5  description: |-
     6    Connect enables secure service-to-service communication over mutual TLS. This
     7    provides both in-transit data encryption as well as authorization. This page
     8    will document how to secure Connect.
     9  ---
    10  
    11  # Connect Security
    12  
    13  Connect enables secure service-to-service communication over mutual TLS. This
    14  provides both in-transit data encryption as well as authorization. This page
    15  will document how to secure Connect. For a full security model reference,
    16  see the dedicated [Consul security model](/docs/internals/security.html) page.
    17  
    18  Connect will function in any Consul configuration. However, unless the checklist
    19  below is satisfied, Connect is not providing the security guarantees it was
    20  built for. The checklist below can be incrementally adopted towards full
    21  security if you prefer to operate in less secure models initially.
    22  
    23  ~> **Warning**: The checklist below should not be considered exhaustive. Please
    24  read and understand the [Consul security model](/docs/internals/security.html)
    25  in depth to assess whether your deployment satisfies the security requirements
    26  of Consul.
    27  
    28  ## Checklist
    29  
    30  ### ACLs Enabled with Default Deny
    31  
    32  Consul must be configured to use ACLs with a default deny policy. This forces
    33  all requests to have explicit anonymous access or provide an ACL token. The
    34  configuration also forces all service-to-service communication to be explicitly
    35  whitelisted via an allow [intention](/docs/connect/intentions.html).
    36  
    37  To learn how to enable ACLs, please see the
    38  [guide on ACLs](/docs/guides/acl.html).
    39  
    40  **If ACLs are enabled but are in default allow mode**, then services will be
    41  able to communicate by default. Additionally, if a proper anonymous token
    42  is not configured, this may allow anyone to edit intentions. We do not recommend
    43  this. **If ACLs are not enabled**, deny intentions will still be enforced, but anyone
    44  may edit intentions. This renders the security of the created intentions
    45  effectively useless.
    46  
    47  ### TCP and UDP Encryption Enabled
    48  
    49  TCP and UDP encryption must be enabled to prevent plaintext communication
    50  between Consul agents. At a minimum, `verify_outgoing` should be enabled
    51  to verify server authenticity with each server having a unique TLS certificate.
    52  `verify_incoming` provides additional agent verification, but doesn't directly
    53  affect Connect since requests must also always contain a valid ACL token.
    54  Clients calling Consul APIs should be forced over encrypted connections.
    55  
    56  See the [Consul agent encryption page](/docs/agent/encryption.html) to
    57  learn more about configuring agent encryption.
    58  
    59  **If encryption is not enabled**, a malicious actor can sniff network
    60  traffic or perform a man-in-the-middle attack to steal ACL tokens, always
    61  authorize connections, etc.
    62  
    63  ### Prevent Unauthorized Access to the Config and Data Directories
    64  
    65  The configuration and data directories of the Consul agent on both
    66  clients and servers should be protected from unauthorized access. This
    67  protection must be done outside of Consul via access control systems provided
    68  by your target operating system.
    69  
    70  The [full Consul security model](/docs/internals/security.html) explains the
    71  risk of unauthorized access for both client agents and server agents. In
    72  general, the blast radius of unauthorized access for client agent directories
    73  is much smaller than servers. However, both must be protected against
    74  unauthorized access.
    75  
    76  ### Prevent Non-Connect Traffic to Services
    77  
    78  For services that are using
    79  [proxies](/docs/connect/proxies.html)
    80  (are not [natively integrated](/docs/connect/native.html)),
    81  network access via their unencrypted listeners must be restricted
    82  to only the proxy. This requires at a minimum restricting the listener
    83  to bind to loopback only. More complex solutions may involve using
    84  network namespacing techniques provided by the underlying operating system.
    85  
    86  For scenarios where multiple services are running on the same machine
    87  without isolation, these services must all be trusted. We call this the
    88  **trusted multi-tenancy** deployment model. Any service could theoretically
    89  connect to any other service via the loopback listener, bypassing Connect
    90  completely. In this scenario, all services must be trusted _or_ isolation
    91  mechanisms must be used.
    92  
    93  For developer or operator access to a service, we recommend
    94  using a local Connect proxy. This is documented in the
    95  [development and debugging guide](/docs/connect/dev.html).
    96  
    97  **If non-proxy traffic can communicate with the service**, this traffic
    98  will not be encrypted or authorized via Connect.