Dynamic registration not matching AND label definitions properly

[Richard-Barrett]

Description

The dynamic DB registration does not match properly when you use resource labels.
The following example showcases the use of env and account, however, the labels are not respected and thus not properly matched.

db_service:
  enabled: yes
  resources:
    - labels:
        env: prod
        account: someaccount

What happened:
The customer has the following architecture

Proxy with resource labels:

db_service:
  enabled: yes
  resources:
    - labels:
        env: prod
        account: someaccount

Which is supposed to only match database labels with env: prod AND account: someaccount.
Databases with different accounts should not get matched with the above proxy, but they do.

What you expected to happen:
Labels should respect multiple T-Value pairs as an AND condition and not OR behavior.

Reproduction Steps

As minimally and precisely as possible, describe step-by-step how to reproduce the problem.

1. Spin up an RDS Instance
2. Install Teleport 8.2.0
3. Create Teleport DB Configs with Labels with Account and Environment metadata

db_service:
  enabled: yes
  resources:
    - labels:
        env: prod
        account: someaccount

5. Full Example:

teleport:
  nodename: prod-someaccount-teleport
  auth_token: x
  ca_pin:
  - sha256:x
  auth_servers:
  - somenameteleport.sh:443
  log:
    output: stderr
    severity: INFO
auth_service:
  enabled: no
ssh_service:
  enabled: yes
  labels:
    service: db-ssh
    env: prod
    account: someaccount
    name: prod-someaccount-teleport
proxy_service:
  enabled: no
app_service:
  enabled: no
db_service:
  enabled: yes
  resources:
    - labels:
        env: prod
        account: someaccount

Server Details

• Teleport version (run teleport version): 8.3.4
• Where are you running Teleport? (e.g. AWS, GCP, Dedicated Hardware): AWS

Debug Logs

Feb 17 07:12:34 ixyz.southeast-1.compute.internal teleport[2658]: 2022-02-17T07:12:34Z INFO [DB:SERVIC] db app-refapp-postgres matches, creating. services/reconciler.go:148
Feb 17 08:06:04 ixyz.ap-southeast-1.compute.internal teleport[2658]: 2022-02-17T08:06:04Z INFO [DB:SERVIC] db app2-refapp-postgres matches, creating. services/reconciler.go:148
Feb 17 08:53:53 ixyz.ap-southeast-1.compute.internal teleport[2658]: 2022-02-17T08:53:53Z INFO [DB:SERVIC] db app3-refapp-postgres matches, creating. services/reconciler.go:148

##NOTE**: CUSTOMER CAN NOT USE TAGS AS A RESULT THEY ARE TRYING TO MITIGATE WITH RESOURCE LABELS DUE TO THE WAY THEY HAVE THEIR ARCHITECTURE SET UP!!!

[smallinsky]

@Richard-Barrett
I have tried to reproduce it with different configuration and v8, v9 teleport version mix and I was unable to reproduce the described issue:

I used following setup:

db agent config:

db_service:
  enabled: true
  resources:
    - labels:
       env: prod
       account: acc1

db dynamic rersource:

kind: db
version: v3
metadata:
  name: example1
  labels:
    env: prod
    account: acc1
spec:
  protocol: "postgres"
  uri: "localhost:5432"
---
kind: db
version: v3
metadata:
  name: example2
  labels:
    env: prod
    account: acc2
spec:
  protocol: "postgres"
  uri: "localhost:5432"
---
kind: db
version: v3
metadata:
  name: example3
  labels:
    env: dev
    account: acc1
spec:
  protocol: "postgres"
  uri: "localhost:5432"
---
kind: db
version: v3
metadata:
  name: example4
  labels:
    env: dev
    account: acc2
spec:
  protocol: "postgres"
  uri: "localhost:5432"

And after creation of db example* resource I can observe correct behavior where only the example1 db resource is matched agains env: dev AND account: acc1 db agent matcher

2022-04-21T17:12:49+02:00 INFO [DB:SERVIC] db example1 matches, creating. services/reconciler.go:148
2022-04-21T17:12:49+02:00 DEBU [DB:SERVIC] db example2 doesn't match, not creating. services/reconciler.go:154
2022-04-21T17:12:49+02:00 DEBU [DB:SERVIC] db example3 doesn't match, not creating. services/reconciler.go:154
2022-04-21T17:12:49+02:00 DEBU [DB:SERVIC] db example4 doesn't match, not creating. services/reconciler.go:154

Could you provide the config where this issue can be observed or point out what is the difference between upper-mentioned configuration and the config described in the issue ?

[hyphen-jaydenzheng]

@smallinsky Hey Marek, as per our testing this is the same result. Apparently it seems if you only used the localhost without any aws in the URI or region that will work...

kind:db with uri: "localhost:3306" will follow the pattern, but not:

kind:db with uri: "x-x-x-mysql.xxxx.ap-southeast-1.rds.amazonaws.com:3306"

or

kind:db with uri: "localhost:3306" but also list the aws_region

  aws:
    # Region the database is deployed in.
    region: "ap-southeast-1"

[smallinsky]

Fixed in #11868