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

Adds changes from #1837 to all products and versions #1867

Merged
merged 1 commit into from
Feb 4, 2025
+864 −0
Merged

Adds changes from #1837 to all products and versions #1867

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
Loading
Loading status checks…
Adds changes from GH#1837 to all products and versions
@ctauchen
ctauchen committed Jan 30, 2025

Unverified

This user has not yet uploaded their public signing key.
GPG key ID: DDE3C2E291DB9EE7
Learn about vigilant mode
commit 7313375e77e6bce547339fe67f817595954cbda5
72 changes: 72 additions & 0 deletions calico-cloud/reference/resources/bgppeer.mdx
View file
Original file line number Diff line number Diff line change
@@ -88,6 +88,78 @@
| name | The name of the secret | string |
| key | The key within the secret | string |

:::warning

$[prodname] must be able to read the referenced secret.

Check failure on line 93 in calico-cloud/reference/resources/bgppeer.mdx

GitHub Actions / runner / vale 

[vale] reported by reviewdog 🐶
[Vale.Spelling] Did you really mean 'prodname'?

Raw Output:
{"message": "[Vale.Spelling] Did you really mean 'prodname'?", "location": {"path": "calico-cloud/reference/resources/bgppeer.mdx", "range": {"start": {"line": 93, "column": 3}}}, "severity": "ERROR"}

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: calico-system
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: calico-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: calico-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
72 changes: 72 additions & 0 deletions calico-cloud_versioned_docs/version-20-2/reference/resources/bgppeer.mdx
View file
Original file line number Diff line number Diff line change
@@ -88,6 +88,78 @@
| name | The name of the secret | string |
| key | The key within the secret | string |

:::warning

$[prodname] must be able to read the referenced secret.

Check failure on line 93 in calico-cloud_versioned_docs/version-20-2/reference/resources/bgppeer.mdx

GitHub Actions / runner / vale 

[vale] reported by reviewdog 🐶
[Vale.Spelling] Did you really mean 'prodname'?

Raw Output:
{"message": "[Vale.Spelling] Did you really mean 'prodname'?", "location": {"path": "calico-cloud_versioned_docs/version-20-2/reference/resources/bgppeer.mdx", "range": {"start": {"line": 93, "column": 3}}}, "severity": "ERROR"}

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: calico-system
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: calico-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: calico-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
72 changes: 72 additions & 0 deletions calico-enterprise/reference/resources/bgppeer.mdx
View file
Original file line number Diff line number Diff line change
@@ -90,6 +90,78 @@
| name | The name of the secret | string |
| key | The key within the secret | string |

:::warning

$[prodname] must be able to read the referenced secret.

Check failure on line 95 in calico-enterprise/reference/resources/bgppeer.mdx

GitHub Actions / runner / vale 

[vale] reported by reviewdog 🐶
[Vale.Spelling] Did you really mean 'prodname'?

Raw Output:
{"message": "[Vale.Spelling] Did you really mean 'prodname'?", "location": {"path": "calico-enterprise/reference/resources/bgppeer.mdx", "range": {"start": {"line": 95, "column": 3}}}, "severity": "ERROR"}

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: calico-system
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: calico-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: calico-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
72 changes: 72 additions & 0 deletions calico-enterprise_versioned_docs/version-3.17/reference/resources/bgppeer.mdx
View file
Original file line number Diff line number Diff line change
@@ -90,6 +90,78 @@
| name | The name of the secret | string |
| key | The key within the secret | string |

:::warning

$[prodname] must be able to read the referenced secret.

Check failure on line 95 in calico-enterprise_versioned_docs/version-3.17/reference/resources/bgppeer.mdx

GitHub Actions / runner / vale 

[vale] reported by reviewdog 🐶
[Vale.Spelling] Did you really mean 'prodname'?

Raw Output:
{"message": "[Vale.Spelling] Did you really mean 'prodname'?", "location": {"path": "calico-enterprise_versioned_docs/version-3.17/reference/resources/bgppeer.mdx", "range": {"start": {"line": 95, "column": 3}}}, "severity": "ERROR"}

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: calico-system
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: calico-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: calico-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
72 changes: 72 additions & 0 deletions calico-enterprise_versioned_docs/version-3.18-2/reference/resources/bgppeer.mdx
View file
Original file line number Diff line number Diff line change
@@ -90,6 +90,78 @@
| name | The name of the secret | string |
| key | The key within the secret | string |

:::warning

$[prodname] must be able to read the referenced secret.

Check failure on line 95 in calico-enterprise_versioned_docs/version-3.18-2/reference/resources/bgppeer.mdx

GitHub Actions / runner / vale 

[vale] reported by reviewdog 🐶
[Vale.Spelling] Did you really mean 'prodname'?

Raw Output:
{"message": "[Vale.Spelling] Did you really mean 'prodname'?", "location": {"path": "calico-enterprise_versioned_docs/version-3.18-2/reference/resources/bgppeer.mdx", "range": {"start": {"line": 95, "column": 3}}}, "severity": "ERROR"}

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: calico-system
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: calico-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: calico-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
72 changes: 72 additions & 0 deletions calico-enterprise_versioned_docs/version-3.19-2/reference/resources/bgppeer.mdx
View file
Original file line number Diff line number Diff line change
@@ -90,6 +90,78 @@
| name | The name of the secret | string |
| key | The key within the secret | string |

:::warning

$[prodname] must be able to read the referenced secret.

Check failure on line 95 in calico-enterprise_versioned_docs/version-3.19-2/reference/resources/bgppeer.mdx

GitHub Actions / runner / vale 

[vale] reported by reviewdog 🐶
[Vale.Spelling] Did you really mean 'prodname'?

Raw Output:
{"message": "[Vale.Spelling] Did you really mean 'prodname'?", "location": {"path": "calico-enterprise_versioned_docs/version-3.19-2/reference/resources/bgppeer.mdx", "range": {"start": {"line": 95, "column": 3}}}, "severity": "ERROR"}

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: calico-system
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: calico-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: calico-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
72 changes: 72 additions & 0 deletions calico-enterprise_versioned_docs/version-3.20-1/reference/resources/bgppeer.mdx
View file
Original file line number Diff line number Diff line change
@@ -90,6 +90,78 @@
| name | The name of the secret | string |
| key | The key within the secret | string |

:::warning

$[prodname] must be able to read the referenced secret.

Check failure on line 95 in calico-enterprise_versioned_docs/version-3.20-1/reference/resources/bgppeer.mdx

GitHub Actions / runner / vale 

[vale] reported by reviewdog 🐶
[Vale.Spelling] Did you really mean 'prodname'?

Raw Output:
{"message": "[Vale.Spelling] Did you really mean 'prodname'?", "location": {"path": "calico-enterprise_versioned_docs/version-3.20-1/reference/resources/bgppeer.mdx", "range": {"start": {"line": 95, "column": 3}}}, "severity": "ERROR"}

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: calico-system
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: calico-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: calico-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
72 changes: 72 additions & 0 deletions calico-enterprise_versioned_docs/version-3.20-2/reference/resources/bgppeer.mdx
View file
Original file line number Diff line number Diff line change
@@ -90,6 +90,78 @@
| name | The name of the secret | string |
| key | The key within the secret | string |

:::warning

$[prodname] must be able to read the referenced secret.

Check failure on line 95 in calico-enterprise_versioned_docs/version-3.20-2/reference/resources/bgppeer.mdx

GitHub Actions / runner / vale 

[vale] reported by reviewdog 🐶
[Vale.Spelling] Did you really mean 'prodname'?

Raw Output:
{"message": "[Vale.Spelling] Did you really mean 'prodname'?", "location": {"path": "calico-enterprise_versioned_docs/version-3.20-2/reference/resources/bgppeer.mdx", "range": {"start": {"line": 95, "column": 3}}}, "severity": "ERROR"}

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: calico-system
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: calico-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: calico-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
72 changes: 72 additions & 0 deletions calico_versioned_docs/version-3.26/reference/resources/bgppeer.mdx
View file
Original file line number Diff line number Diff line change
@@ -89,6 +89,78 @@
| name | The name of the secret | string |
| key | The key within the secret | string |

:::warning

$[prodname] must be able to read the referenced secret.

Check failure on line 94 in calico_versioned_docs/version-3.26/reference/resources/bgppeer.mdx

GitHub Actions / runner / vale 

[vale] reported by reviewdog 🐶
[Vale.Spelling] Did you really mean 'prodname'?

Raw Output:
{"message": "[Vale.Spelling] Did you really mean 'prodname'?", "location": {"path": "calico_versioned_docs/version-3.26/reference/resources/bgppeer.mdx", "range": {"start": {"line": 94, "column": 3}}}, "severity": "ERROR"}

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: calico-system # Or kube-system if installed using manifests.
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: calico-system # Or kube-system if installed using manifests.
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: calico-system # Or kube-system if installed using manifests.
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
72 changes: 72 additions & 0 deletions calico_versioned_docs/version-3.27/reference/resources/bgppeer.mdx
View file
Original file line number Diff line number Diff line change
@@ -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

$[prodname] 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: calico-system # Or kube-system if installed using manifests.
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: calico-system # Or kube-system if installed using manifests.
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: calico-system # Or kube-system if installed using manifests.
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
72 changes: 72 additions & 0 deletions calico_versioned_docs/version-3.28/reference/resources/bgppeer.mdx
View file
Original file line number Diff line number Diff line change
@@ -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

$[prodname] 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: calico-system # Or kube-system if installed using manifests.
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: calico-system # Or kube-system if installed using manifests.
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: calico-system # Or kube-system if installed using manifests.
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
72 changes: 72 additions & 0 deletions calico_versioned_docs/version-3.29/reference/resources/bgppeer.mdx
View file
Original file line number Diff line number Diff line change
@@ -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

$[prodname] 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: calico-system # Or kube-system if installed using manifests.
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: calico-system # Or kube-system if installed using manifests.
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: calico-system # Or kube-system if installed using manifests.
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