Ok, got it.

The question is from there may have some limitations in Consumer, if we
want to implement API market by using Consumer, then how to implement 1
service with N packages? and allow the same user buying different packages
in one service? This is another question of course ^_^

Anyone, we are going to discuss your proposal.

Chao Zhang <tok...@apache.org>于2021年4月13日 周二下午2:32写道:

> Hi, Zhiyuan
>
> > Just to make sure, does Ingress Controller have the same action like
> APISIX
> > does? Could we need to support scoped Consumer?
>
> I'm not sure what you mean by saying scoped Consumer.
>
> All the actions that APISIX Ingress Controller does totally obeys the
> design of APISIX
> but with some high-level abstractions and encapsulations.
>
> Thanks!
> Chao Zhang
> GitHub: https://github.com/tokers
>
> On Tue, Apr 13, 2021 at 2:27 PM Zhiyuan Ju <juzhiy...@apache.org> wrote:
> >
> > Hi,
> >
> > Thanks for your sharing and proposal.
> >
> > I noticed that there mentioned the ApisixConsumer, Consumer in APISIX is
> > more like a global level consumer, when we create one in APISIX, we only
> > need to enable the same Auth Plugin in Routes then they will bind
> together.
> >
> > Just to make sure, does Ingress Controller have the same action like
> APISIX
> > does? Could we need to support scoped Consumer?
> >
> > Best Regards!
> > @ Zhiyuan Ju <https://github.com/juzhiyuan>
> >
> >
> > Chao Zhang <tok...@apache.org> 于2021年4月13日周二 下午1:51写道:
> >
> > > Hi, there
> > >
> > > I'm devoting myself to implementing the authentication capability in
> > > APISIX Ingress Controller, and below is my proposal.
> > >
> > > Background
> > >
> > > Authentication and Authorization are required on the Kubernetes
> > > Ingress layer, which is similar to API Gateway. However, due to the
> > > lack of some APISIX Consumer alike stuff, APISIX Ingress Controller
> > > cannot leverage any Authentication plugins provided by APISIX.
> > >
> > > That’s why an appropriate way needs to be developed to make up for
> > > this drawback.
> > >
> > > Research
> > >
> > > The standard Ingress isn’t involve anything about Authentication, thus
> > > every Ingress Controllers implement it in different ways.
> > >
> > > Kong
> > >
> > > As an API Gateway solution, Kong Ingress Controller implements the
> > > KongConsumer CRD,  which maps it to the Consumer object in Kong.
> > >
> > > apiVersion: configuration.konghq.com/v1
> > > kind: KongConsumer
> > > metadata:
> > >   name: <object name>
> > >   namespace: <object namespace>
> > >   annotations:
> > >     kubernetes.io/ingress.class: <controller ingress class, "kong" by
> > > default>
> > > username: <user name>
> > > custom_id: <custom ID>
> > >
> > > All KongConsumer resources will be watched by Kong Ingress Controller
> > > and used when authenticating.
> > >
> > > Ingress Nginx
> > >
> > > The Authentication is weak in Ingress Nginx,only basic-auth and digest
> > > authentication are supported. It is implemented by specifying
> > > annotations in Ingress.
> > >
> > > nginx.ingress.kubernetes.io/auth-type: [basic|digest]
> > >
> > > This annotation specifies the authentication type.
> > >
> > > nginx.ingress.kubernetes.io/auth-secret: secretName
> > >
> > > And this annotation specifies the Kubernetes Secret name which stores
> > > the username and password.
> > >
> > > apiVersion: v1
> > > data:
> > >   auth: Zm9vOiRhcHIxJE9GRzNYeWJwJGNrTDBGSERBa29YWUlsSDkuY3lzVDAK
> > > kind: Secret
> > > metadata:
> > >   name: basic-auth
> > >   namespace: default
> > > type: Opaque
> > > ---
> > > apiVersion: networking.k8s.io/v1beta1
> > > kind: Ingress
> > > metadata:
> > >   name: ingress-with-auth
> > >   annotations:
> > >     nginx.ingress.kubernetes.io/auth-type: basic
> > >     nginx.ingress.kubernetes.io/auth-secret: basic-auth
> > > spec:
> > >   rules:
> > >   - host: foo.bar.com
> > >     http:
> > >       paths:
> > >       - path: /
> > >         backend:
> > >           serviceName: http-svc
> > >           servicePort: 80
> > >
> > > How Consumers Work in APISIX
> > >
> > > Consumers are always used with Authentication, you need to configure a
> > > consumer (with username) and enable several plugins on it, then also
> > > enabling these (auth) plugins in the Route. APISIX searches the
> > > consumer according to the auth-type and its key (headers or query
> > > strings).
> > >
> > > Frankly, it also works if we just copy this way to APISIX Ingress
> > > Controller, but the configure is not so clean and easy. As we first
> > > need some kinds of stuff to create the Consumer, then enable (APISIX)
> > > plugins on it, and enabling these plugins on ApisixRoute again. We
> > > need an easier way.
> > >
> > > ApisixConsumer
> > >
> > > ApisixConsumer is necessary as we have to create the consumer.
> > >
> > > apiVersion: apisix.apache.org/v2alpha1
> > > kind: ApisixConsumer
> > > metadata:
> > >   name: <consumer-name>
> > >   namespace: <consumer-namespace>
> > >   labels:
> > >     group: 111
> > > spec:
> > >   authParameter:
> > >     basicAuth:
> > >       valueRef: # exclusive with value
> > >         kind: secret
> > >         name: <secret-name>
> > >         namespace: <secret-namespace>
> > >       value: # exclusive with valueRef
> > >         username: aaa
> > >         password: xxx
> > >     keyAuth:
> > >       key: xxxx # exclusive with keyRef
> > >       keyRef: # exclusive with key
> > >         kind: secret
> > >         name: <secret-name>
> > >         namespace: <secret-namespace>
> > >
> > > Currently, only fields under authParameter are concerned (other
> > > features like limit-rate, can be put under rateLimiting field and so
> > > on), which represents authentications, more auth types can be
> > > implemented there, values are kind-dependent, for instance, basic auth
> > > needs a username and password configuration in value or importing from
> > > a secret (exclusively), in valueRef.
> > >
> > > All ApisixConsumers will be watched by APISIX Ingress Controller, and
> > > corresponding Consumer objects will be created, which name is
> > > concatenated by the namespace and name (so it can be unique).
> > >
> > > All authentication configurations will be translated to the
> > > corresponding underlying plugins.
> > >
> > > You may wonder that why not just using the native plugin way here.
> > > This is because the fields above (e.g. password in basic auth) are
> > > sensitive and just configuring literally is not so safe, a better way
> > > is fetching them from Kubernetes secret, also, the native plugin
> > > configuring is too flexible to manage, it might results in some
> > > security issues (since validation is not so strong so far).
> > >
> > > ApisixRoute
> > >
> > > On the other hand, authentication should be enabled in ApisixRoute, of
> > > course, it can be supported by configuring the plugins field:
> > >
> > > apiVersion: apisix.apache.org/v2alpha1
> > > kind: ApisixRoute
> > > metadata:
> > >   name: test
> > > spec:
> > >   http:
> > >   - name: rule1
> > >     match:
> > >       paths:
> > >       - /*
> > >     backend:
> > >       serviceName: httpbin
> > >       servicePort: 8080
> > >     plugins:
> > >     - name: basic-auth
> > >       enable: true
> > >
> > > Considering some capabilities like consumer restriction (ACL) and a
> > > unifying way for management, native fields will be better here.
> > >
> > > apiVersion: apisix.apache.org/v2alpha1
> > > kind: ApisixRoute
> > > metadata:
> > >   name: test
> > > spec:
> > >   http:
> > >   - name: rule1
> > >     match:
> > >       paths:
> > >       - /*
> > >     backend:
> > >       serviceName: httpbin
> > >       servicePort: 8080
> > >     authentication:
> > >       enable: true
> > >       type: keyAuth
> > >       keyAuth:
> > >         header: Authorization
> > >       acl:
> > >         allowedConsumers:
> > >           selector:
> > >             group: 111
> > >         deniedConsumers:
> > >           selector:
> > >             group: 222
> > >         rejectedCode: 503
> > >
> > > Just enabling the required authentication way in ApisixRoute and
> > > configuring the ACL (consumer restriction) on demand.
> > >
> > > In practice, people won’t configure more than one authentication
> > > method in a Route, so here the authentication type must be configured,
> > > any extra configurations can be put under another field which name is
> > > the same as the authentication type (e.g. configurations for keyAuth
> > > is under keyAuth field).
> > >
> > > As for ACL, Kuberentes typical label-selector is applied as the
> > > consumer list might be huge. In this case, it’s not easy to maintain
> > > such an ApisixRoute object.
> > >
> > > All the authentications and ACL will be translated to the underlying
> > > APISIX plugins.
> > >
> > > Thanks!
> > > Chao Zhang
> > > GitHub: https://github.com/tokers
> > >
>
-- 
来自 琚致远

Reply via email to