github.com/argoproj/argo-cd/v2@v2.10.9/docs/developer-guide/architecture/authz-authn.md (about)

     1  # Authentication and Authorization
     2  
     3  This document describes how authentication (authn) and authorization
     4  (authz) are implemented in Argo CD. There is a clear distinction in
     5  the code base of when and how these two security concepts are
     6  enforced.
     7  
     8  ## Logical layers
     9  
    10  The diagram bellow suggests 4 different logical layers (represented by
    11  4 boxes: HTTP, gRPC, AuthN and AuthZ) inside Argo CD API server that
    12  collaborate to provide authentication and authorization. 
    13  
    14  - **HTTP**: The HTTP layer groups the *logical elements* that
    15    collaborate to handle HTTP requests. Every incoming request reaches
    16    the same HTTP server at the same port (8080). This server will
    17    analyze the request headers and dispatch to the proper internal
    18    server: gRPC or standard HTTP.
    19  
    20  - **gRPC**: The [gRPC][4] layer groups the logical elements responsible for
    21    the gRPC implementation.
    22  
    23  - **AuthN**: The AuthN represents the layer responsible for
    24    authentication.
    25  
    26  - **AuthZ**: The AuthZ represents the layer responsible for
    27    authorization.
    28  
    29  ![Argo CD Architecture](../../assets/argocd-arch-authn-authz.jpg)
    30  
    31  ## Logical elements
    32  
    33  The logical elements (identified by numbers) can represent an object,
    34  a function or a component in the code base. Note that this particular
    35  distinction is not represented in the diagram.
    36  
    37  Incoming requests can reach Argo CD API server from the web UI as well
    38  as from the `argocd` CLI. The responsibility of the represented
    39  elements are described below with their respective numbers:
    40  
    41  1. **Cmux**: Uses the [cmux][1] library to provide a connection
    42     multiplexer capability making it possible to use the same port to
    43     handle standard HTTP as well as gRPC requests. It is responsible
    44     for inspecting incoming requests and dispatch to appropriate
    45     internal servers. If the request version is `http1.x` it will
    46     delegate to the *http mux*. If the request version is `http2` and
    47     has the header `content-type: application/grpc`, it will delegate
    48     to the *gRPC Server*.
    49  
    50  1. **HTTP mux**: A [standard HTTP multiplexer][8] that will handle non
    51     gRPC requests. It is responsible for serving a unified [REST
    52     API][3] to the web UI exposing all gRPC and non-gRPC services.
    53  
    54  1. **gRPC-gateway**: Uses the [grpc-gateway][2] library to translate
    55     internal gRPC services and expose them as a [REST API][3]. The
    56     great majority of API services in Argo CD are implemented in gRPC.
    57     The grpc-gateway makes it possible to access gRPC services from the
    58     web UI.
    59  
    60  1. **Server**: The internal gRPC Server responsible for handling gRPC
    61     requests.
    62  
    63  1. **AuthN**: Is responsible for invoking the authentication logic. It
    64     is registered as a gRPC interceptor which will automatically
    65     trigger for every gRPC request.
    66  
    67  1. **Session Manager**: Is the object responsible for managing Argo CD
    68     API server session. It provides the functionality to verify the
    69     validity of the authentication token provided in the request.
    70     Depending on how Argo CD is configured it may or may not delegate
    71     to an external AuthN provider to verify the token.
    72  
    73  1. **AuthN Provider**: Describes the component that can be plugged in
    74     Argo CD API server to provide the authentication functionality such
    75     as the login and the token verification process.
    76  
    77  1. **Service Method**: represents the method implementing the business
    78     logic (core functionality) requested. An example of business logic
    79     is: `List Applications`. Service methods are also responsible for
    80     invoking the [RBAC][7] enforcement function to validate if the
    81     authenticated user has permission to execute this method.
    82  
    83  1. **RBAC**: Is a collection of functions to provide the capability to
    84     verify if the user has permission to execute a specific action in
    85     Argo CD. It does so by validating the incoming request action
    86     against predefined [RBAC][7] rules that can be configured in Argo CD
    87     API server as well as in Argo CD `Project` CRD.
    88  
    89  1. **Casbin**: Uses the [Casbin][5] library to enforce [RBAC][7] rules.
    90  
    91  1. **AuthN Middleware**: Is an [HTTP Middleware][6] configured to
    92     invoke the logic to verify the token for HTTP services that are not
    93     implemented as gRPC and requires authentication.
    94  
    95  1. **HTTP Handler**: represents the http handlers responsible for
    96     invoking the business logic (core functionality) requested. An
    97     example of business logic is: `List Applications`. Http handlers
    98     are also responsible for invoking the [RBAC][7] enforcement function to
    99     validate if the authenticated user has permission to execute this
   100     business logic.
   101  
   102  [1]: https://github.com/soheilhy/cmux
   103  [2]: https://github.com/grpc-ecosystem/grpc-gateway
   104  [3]: https://en.wikipedia.org/wiki/Representational_state_transfer
   105  [4]: https://grpc.io/
   106  [5]: https://casbin.org/
   107  [6]: https://github.com/golang/go/wiki/LearnServerProgramming#middleware
   108  [7]: https://en.wikipedia.org/wiki/Role-based_access_control
   109  [8]: https://pkg.go.dev/net/http#ServeMux