You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: docs/for-devs/console/code-repositories.md
+2-2Lines changed: 2 additions & 2 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -44,7 +44,7 @@ All registered code repositories of the Team are listed here.
44
44
45
45
2. Optionally: Select `Private` If the repository in GitHub is private.
46
46
47
-
3. Optionally: Select a secret that contains the authentication credentials. Only Sealed Secrets of type `basic-auth` and `ssh-auth` will be shown. If no secret is available, then first [create a Sealed Secret](sealed-secrets.md).
47
+
3. Optionally: Select a secret that contains the authentication credentials. Only secrets of type `basic-auth` and `ssh-auth` will be shown. If no secret is available, then first [create a secret](secrets.md).
48
48
49
49
4. Optionally: Test the connection to see if the authentication credentials are valid and App Platform can use the credentials to access the private repository.
50
50
@@ -57,7 +57,7 @@ All registered code repositories of the Team are listed here.
57
57
58
58
2. Optionally: Select `Private` If the repository in GitLab is private.
59
59
60
-
3. Optionally: Select a secret that contains the authentication credentials. Only Sealed Secrets of type `basic-auth` and `ssh-auth` will be shown. If no secret is available, then first [create a Sealed Secret](sealed-secrets.md).
60
+
3. Optionally: Select a secret that contains the authentication credentials. Only secrets of type `basic-auth` and `ssh-auth` will be shown. If no secret is available, then first [create a secret](secrets.md).
61
61
62
62
4. Optionally: Test the connection to see if the authentication credentials are valid and App Platform can use the credentials to access the private repository.
Sealed Secrets are encrypted Kubernetes Secrets. The encrypted secrets are stored in the Values Git repository. When a Sealed Secrets secret is created in the Console, the Kubernetes Secret will appear in the Team's namespace and can be used as you would use any secret that you would have created directly.
7
+
Secrets in the Console are securely encrypted and stored in your Values Git repository using Sealed Secrets. When you create a secret in the Console, it generates a standard Kubernetes Secret in your Team's namespace that can be used like any other Kubernetes secret.
8
8
9
-
7 types of secrets are supported:
9
+
6 types of secrets are supported:
10
10
11
11
- Opaque
12
-
- Service Account Token
13
12
- Docker Config
14
13
- Docker Config Json
15
14
- Basic Auth
16
15
- SSH Auth
17
16
- TLS
18
17
19
-
## Create a Sealed Secret
18
+
## Create a Secret
20
19
21
-
1. Provide a name for the Sealed Secret. The Kubernetes secret will have the same name.
20
+
1. Provide a name for the Secret. The Kubernetes secret will have the same name.
22
21
23
-
2. Select `Immutable` if the data of the Sealed Secret (and the Kubernetes secret) can not be updated after the Sealed Secret has been created. When the Sealed Secret is Immutable, only the metadata can be modified after creation.
22
+
2. Select `Immutable` if the data of the secret (and the Kubernetes secret) can not be updated after the secret has been created. When the secret is Immutable, only the metadata can be modified after creation.
24
23
25
24
3. Select the Type:
26
25
27
26
### Opaque secret
28
27
29
28
Opaque is the default secret type in Kubernetes. Read more about Opaque secrets [here](https://kubernetes.io/docs/concepts/configuration/secret/#opaque-secrets).
See [here](https://kubernetes.io/docs/concepts/configuration/secret/#serviceaccount-token-secrets") for more information about service account token secrets.
50
-
51
-
You need to ensure that the `kubernetes.io/service-account.name` annotation is set to an existing ServiceAccount name. See the [metadata](#metadata) section for adding annotations.
52
-
53
-
:::note
54
-
The secret value will only be visible at the time of creation or once it has been successfully synchronized with the cluster.
| ssh-privatekey | a `ssh-privatekey` key-value pair in the data field as the SSH credential to use |
118
87
119
-
:::note
120
-
The secret value will only be visible at the time of creation or once it has been successfully synchronized with the cluster.
121
-
:::
122
-
123
88
### TLS secret
124
89
125
90
@@ -129,18 +94,18 @@ The secret value will only be visible at the time of creation or once it has bee
129
94
| tls.key | The private key certificate content |
130
95
131
96
:::note
132
-
The secret value will only be visible at the time of creation or once it has been successfully synchronized with the cluster.
97
+
The secret value will only be visible at the time of creation. After creation, the value field will display asterisks `****` to indicate the data is encrypted and cannot be revealed through the interface, though it can be overwritten. To overwrite the secret, click on the lock `🔒` icon next to the value field, enter the new secret value, and click on `Save Changes`.
133
98
:::
134
99
135
100
136
101
## Metadata
137
102
138
103
Adding metadata is optional.
139
104
140
-
Add the following standard metadata to the sealed-secret:
105
+
Add the following standard metadata to the secret:
141
106
107
+
-`Labels`. See [here](https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/) for more information about labels
142
108
-`Annotations`. See [here](https://kubernetes.io/docs/concepts/overview/working-with-objects/annotations/) for more information about annotations
143
109
-`Finalizers`. See [here](https://kubernetes.io/docs/concepts/overview/working-with-objects/finalizers/) for more information about finalizers
144
-
-`Labels`. See [here](https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/) for more information about labels
145
110
146
-
Click on `+ Add Item` and add a key-value pair.
111
+
Click the corresponding add button (`+Add Labels`, `+Add Annotations` or `+Add Finalizers`) to add key-value pairs.
Copy file name to clipboardExpand all lines: docs/for-devs/security-best-practices.md
+1-1Lines changed: 1 addition & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -6,7 +6,7 @@ sidebar_label: Security Best Practices
6
6
7
7
In addition to the out-of-the-box security capabilities provides by App Platform, it is a responsibility of Teams to keep their applications safe from bad actors. Here is a list of security best-practices Teams should implement:
8
8
9
-
1. Use [secrets](../for-devs/console/sealed-secrets.md) to secure sensitive data and use a `secretKeyRef` to map an environment variable to the secret data.
9
+
1. Use [secrets](../for-devs/console/secrets.md) to secure sensitive data and use a `secretKeyRef` to map an environment variable to the secret data.
10
10
11
11
2. Drop `ALL` or specific capabilities in the Pod or container `SecurityContext` to ensure all (unused) capabilities are disabled.
Copy file name to clipboardExpand all lines: docs/for-ops/console/team-admin-overview.md
+1-1Lines changed: 1 addition & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -13,7 +13,7 @@ Self-service section:
13
13
-[Catalog](team-admin-catalog.md): The Helm charts available for platform administrators to install in any namespace
14
14
-[Code Repositories](team-admin-code-repositories.md): A self-service form for platform administrators to register code repositories.
15
15
-[Container Images](team-admin-container-images.md): A self-service form for platform administrators to create container images from registered code repositories.
16
-
-[Sealed Secrets](team-admin-sealed-secrets.md): A self-service form for platform administrators to create Sealed Secrets.
16
+
-[Secrets](team-admin-secrets.md): A self-service form for platform administrators to create a secret using Sealed Secrets.
17
17
-[Workloads](team-admin-workloads.md): A self-service form to create for platform administrators Workloads in any namespace.
18
18
-[Network Policies](team-admin-netpols.md): A self-service form for platform administrators to create Network Policies (in the `team-admin` namespace only).
19
19
-[Services](team-admin-services.md): A self-service form for platform administrators to create Services to expose endpoints (`ClusterIP` services) from any namespace.
The Secrets self-service feature for the Team Admin is the same as for regular teams. Secrets can only be created in the `team-admin` namespace using Sealed Secrets. See [here](../../for-devs/console/secrets.md) for more information about Secrets.
In this lab we will create a secret using Sealed Secrets and see how to securely store sensitive information in a git repository.
8
+
9
+
## Creating a Secret
10
+
11
+
1. Click on the `Secrets` in the sidebar.
12
+
13
+
2. Click on `Create Secret`. This will take you to the page where you can create a secret.
14
+
15
+
3. Fill in a name for your secret. In this lab we will use the name `secret-credentials`
16
+
17
+
4. Select the secret type. In this lab we will create a secret of type `kubernetes.io/opaque`.
18
+
19
+
5. Click on `+Add another` so you can fill in two key-value pairs
20
+
21
+
6. In the `Secret data` section. Add the following key-value pairs:
22
+
23
+
-`key=password value=helloworld`
24
+
-`key=username value=labs-user`
25
+
26
+

27
+
28
+
7. Click on `Create Secret`.
29
+
30
+
:::note
31
+
The secret value will only be visible at the time of creation. After creation, the value field will display asterisks `****` to indicate the data is encrypted and cannot be revealed through the interface, though it can be overwritten. To overwrite the secret, click on the lock `🔒` icon next to the value field, enter the new secret value, and click on `Save Changes`.
32
+
:::
33
+
34
+

35
+

36
+
37
+
## Checking the GIT repository
38
+
39
+
Now go to Gitea and check the `otomi/values` repository. You will see that under `values/env/teams/<team-name>/sealedsecrets/secret-credentials.yaml` the secret is stored in yaml, but the values are encrypted.
The only way to see the values of the secret is to decrypt the secret. The secret values are stored as base64 encoded values. In the left menu click on Shell and run the following command:
46
+
47
+
```bash
48
+
kubectl get secret secret-credentials -o yaml -n team-labs
49
+
```
50
+
51
+
This wil return the secret in yaml format. The values are stored as base64 encoded values.
52
+
53
+
```yaml
54
+
apiVersion: v1
55
+
data:
56
+
password: aGVsbG93b3JsZA==
57
+
username: bGFicy11c2Vy
58
+
kind: Secret
59
+
metadata:
60
+
creationTimestamp: '2025-11-11T13:44:16Z'
61
+
name: secret-credentials
62
+
namespace: team-labs
63
+
ownerReferences:
64
+
- apiVersion: bitnami.com/v1alpha1
65
+
controller: true
66
+
kind: SealedSecret
67
+
name: secret-credentials
68
+
uid: fc1014f6-0212-49f7-a95d-c4169e053b60
69
+
resourceVersion: '240057431'
70
+
uid: b76d6944-fa91-4392-ba4c-80e3e07c7e82
71
+
type: kubernetes.io/opaque
72
+
```
73
+
74
+
If you want to decode the secret you can use `base64 --decode`. Run the following command:
0 commit comments