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

Add example for Role, RoleBinding and Secret to configure BGP passwords #1837

Open
wants to merge 1 commit into
base: main
Choose a base branch
from
Open

Add example for Role, RoleBinding and Secret to configure BGP passwords #1837

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
72 changes: 72 additions & 0 deletions calico/reference/resources/bgppeer.mdx
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -89,6 +89,78 @@ secret must be in the same namespace as the $[nodecontainer] pod.
| name | The name of the secret | string |
| key | The key within the secret | string |

:::warning

Calico must be able to read the referenced secret!

This means that the `calico-node` ServiceAccount must have permissions to `list, get, watch` the secret referenced in the KeyRef.

In practice, this can be done by creating a Role (which allows to `list, get, watch` the secret) and a RoleBinding (which grants the Role's permission to the `calico-node` ServiceAccount).

Example:

```yaml
---
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
name: bgp-passwords-reader
namespace: kube-system
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we want to default to calico-system (most new installs use the calico-system namespace).

Perhaps this is a use-case for Tabs for "Operator" and "Manifest" installs? We have those elsewhere in the docs.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sure, I don't mind which one is used as example :)

Maybe we could even make it extra-explicit by using something like $NAMESPACE_IN_WHICH_CALICO_IS_RUNNING

That would
a) make it non-copy-paste-able, and thus
b) ensure that people look up the namespace calico is actually running in.

I like these Tabs for the different installation methods because they help keep the docs a bit clearer, but I also think they are better used in the "explanatory" sections of the docs and could be confusing in the Resource Definition Reference.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd be happy with that approach :)

I'll leave it up to @ctauchen as to what the preferred style guideline would be in this case.

rules:
- apiGroups: [""]
resources: ["secrets"]
resourceNames: ["bgp-passwords"]
verbs: ["list", "watch", "get"]

---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: calico-read-bgp-passwords
namespace: kube-system
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: Role
name: bgp-passwords-reader
subjects:
- kind: ServiceAccount
name: calico-node

---
apiVersion: v1
kind: Secret
metadata:
name: "bgp-passwords"
namespace: kube-system
data:
peer_a_pw: "base64-encoded Password for Peer A"
peer_b_pw: "base64-encoded Password for Peer B"

---
apiVersion: crd.projectcalico.org/v1
kind: BGPPeer
metadata:
name: "peer-a"
spec:
password:
secretKeyRef:
name: "bgp-passwords"
key: "peer_a_pw"

---
apiVersion: crd.projectcalico.org/v1
kind: BGPPeer
metadata:
name: "peer-b"
spec:
password:
secretKeyRef:
name: "bgp-passwords"
key: "peer_b_pw"
```

:::

## Peer scopes

BGP Peers can exist at either global or node-specific scope. A peer's scope
Expand Down
Loading