Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Not Removing Previous Roles and Users within iamAuthenticatorConfig #4740

Open
wcrum opened this issue Jan 15, 2024 · 3 comments · May be fixed by #4919
Open

Not Removing Previous Roles and Users within iamAuthenticatorConfig #4740

wcrum opened this issue Jan 15, 2024 · 3 comments · May be fixed by #4919
Labels
kind/bug Categorizes issue or PR as related to a bug. needs-priority triage/accepted Indicates an issue or PR is ready to be actively worked on.

Comments

@wcrum
Copy link

wcrum commented Jan 15, 2024

/kind bug

What steps did you take and what happened:
Updating iamAuthenticatorConfig with multiple roles or users, then removing roles does not remove old roles and users, only appends new arns.

  1. Define CAPA iamAuthenticatorConfig.
iamAuthenticatorConfig:
  mapUsers:
  - groups:
    - system:masters
    userarn: arn:aws:iam::111122223333:user/my-user
    username: my-user
  - groups:
    - system:masters
    userarn: arn:aws:iam::111122223333:user/my-second-user
    username: my-second-user
  1. Define iamAuthenticatorConfig removing a user.
iamAuthenticatorConfig:
  mapUsers:
  - groups:
    - system:masters
    userarn: arn:aws:iam::111122223333:user/my-second-user
    username: my-second-user
  1. Result within kube-system/aws-auth.
   mapUsers: |                                                                                                                                                                            
     - groups:                                                                                                                                                                           
       - system:masters                                                                                                                                                                   
       userarn: arn:aws:iam::111122223333:user/my-user                                                                                                                                     
       username: my-user
     - groups:                                                                                                                                                                           
       - system:masters                                                                                                                                                                   
       userarn: arn:aws:iam::111122223333:user/my-second-user                                                                                                                                 
       username: my-second-user

What did you expect to happen:
The expected behavior is to have kube-system/aws-auth to only have the defined users / roles.

   mapUsers: |                                                                                                                                                                            
     - groups:                                                                                                                                                                           
       - system:masters                                                                                                                                                                   
       userarn: arn:aws:iam::111122223333:user/my-second-user                                                                                                                                 
       username: my-second-user

Anything else you would like to add:
Would like to clarify if this is expected or unexpected behavior. Not removing users / roles could be a security risk.

Environment:

  • Cluster-api-provider-aws version: v2.3.1
  • Kubernetes version: (use kubectl version): v1.28.4
  • OS (e.g. from /etc/os-release): macOS 14.1.1 (23B81)
@k8s-ci-robot k8s-ci-robot added kind/bug Categorizes issue or PR as related to a bug. needs-priority needs-triage Indicates an issue or PR lacks a `triage/foo` label and requires one. labels Jan 15, 2024
@wcrum wcrum mentioned this issue Jan 15, 2024
Closed
5 tasks
@wcrum wcrum linked a pull request Apr 10, 2024 that will close this issue
Open
5 tasks
@k8s-triage-robot
Copy link

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

  • After 90d of inactivity, lifecycle/stale is applied
  • After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
  • After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

  • Mark this issue as fresh with /remove-lifecycle stale
  • Close this issue with /close
  • Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

@k8s-ci-robot k8s-ci-robot added the lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. label Apr 14, 2024
@k8s-triage-robot
Copy link

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

  • After 90d of inactivity, lifecycle/stale is applied
  • After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
  • After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

  • Mark this issue as fresh with /remove-lifecycle rotten
  • Close this issue with /close
  • Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle rotten

@k8s-ci-robot k8s-ci-robot added lifecycle/rotten Denotes an issue or PR that has aged beyond stale and will be auto-closed. and removed lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. labels May 14, 2024
@nrb
Copy link
Contributor

nrb commented May 31, 2024

/remove-lifecycle rotten
/triage accepted

@k8s-ci-robot k8s-ci-robot added triage/accepted Indicates an issue or PR is ready to be actively worked on. and removed lifecycle/rotten Denotes an issue or PR that has aged beyond stale and will be auto-closed. needs-triage Indicates an issue or PR lacks a `triage/foo` label and requires one. labels May 31, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
kind/bug Categorizes issue or PR as related to a bug. needs-priority triage/accepted Indicates an issue or PR is ready to be actively worked on.
Projects
None yet
Milestone
No milestone
4 participants
@nrb @k8s-ci-robot @wcrum @k8s-triage-robot